√DevOps时代社区与高效运维社区倾情奉献
√40位DevOps专家联袂打造
√115个案例分享技巧与规范
√1349条计策凝聚经验与智慧
新型的DevOps涵括了从需求提出到软件发布的整个软件生命周期,是产品设计、项目管理、开发、测试和运维提升的必由之路,国内大型互联网企业已经做了很多探索,并将相关技能规范化、文档化、工具化、自动化甚至智能化。遗憾的是,这些宝贵经验往往仅在团队或公司内部分享,很多中小公司还在重复走着大公司走过的弯路。
为了促进先进经验在整个行业内分享和传播,DevOps时代社区和高效运维社区邀请了40位业界大咖,从精益、敏捷、开发、测试、运维、架构、安全等各个方面分享他们在Top互联网公司及领先的传统企业工作多年的智慧和经验结晶。本书共有36篇文章,1349条计策,其中很多计策都是在经历了刻骨铭心的事故后总结出来的,精选的115个案例则是对相关计策的解读。
本书旨在总结经验、交流分享,让国内互联网及传统企业缩短成长路径、避免无谓的反复踩坑,让技术人员更好地聚焦于业务目标和业务产出。
本书主编为萧田国和梁定安,欢迎提出宝贵意见和建议。
DevOps时代社区
DevOps时代社区是国内第1个真正有组织的DevOps领域技术社区,也是国际上早期的DevOps 标准体系之一“研发运营一体化能力成熟度模型”的主要组织方(该系列标准由云计算开源产业联盟牵头,已正式在工信部立项)。DevOps时代公众号创办于2017年3月,在不到一年的时间里,订阅用户数已达20 000+。DevOps时代社区正处于急速发展中,成员来自精益、敏捷、开发、测试和运维等领域。
高效运维社区
高效运维社区是国内第1个也是超大的运维领域垂直技术社区,截至2018年2月,高效运维公众号订阅用户数达到100 000+,创办两年多以来,文章阅读量累计6 000 000+人次,是国内运维行业升级转型的主力推手。
高效运维社区是国际上第1个AIOps标准及白皮书的主要组织方(该标准由云计算开源产业联盟牵头,正在工信部立项中),核心编写专家来自互联网优秀企业BATJ,以及金融、制造业、物流等众多领域的领头企业。
赞 誉 致 辞
《DevOps 三十六计》凝聚了一大批业内专家多年的实战经验,是一本难得的实战手册,是大家智慧的结晶。
——何宝宏,中国信息通信研究院云计算和大数据所所长
作为中国初代互联网人,我非常欣喜地看到《DevOps 三十六计》的正式出版发行,从一年多前的小册子,到汇聚了国内精益、敏捷、开发、测试、运维及安全领域大咖专家的著作。36 篇文章,1000 多条计策,其中很多计策都值得我们细细琢磨,相信对相关工作的展开不无裨益。
——吴华鹏,iTech Club(互联网精英俱乐部)理事长
基于技术人的情怀,吴华鹏先生创办了1024 学院。惊喜于1024 学院第二届CTO 班班长萧田国同学组织策划的《DevOps 三十六计》一书,从无到有,从小到大,从粗到精,实乃用心之作,必将成为广大互联网同仁的实用工具书之一。
——佟永跃,1024 学院 CEO
Very little is accomplished without having an actual strategy. This is especially true in DevOps. A cavalier attitude towards DevOps adoption because you think “it just happens” is a sure recipe for failure. Thirty Six Stratagems of DevOps is the perfect guide for you to chart your own DevOps strategy and course. It covers all of the basics you need to get started, as well as specific strategies for specific tools and goals. As the first Chinese DevOps book written by Chinese DevOps experts it represents a new source of guidance and wisdom for the entire, world-wide DevOps community. I highly recommend this book to anyone seeking to learn more about DevOps.
——Alan Shimel, DevOps.com 主编
无论是互联网行业还是传统行业,大家都迫切需要不断地缩短GTM时间。DevOps 是目前加快从需求到应用上线的上好途径。DevOps 时代社区和高效运维社区在这方面做了大量的工作,将业内多位专家的一线实践经验凝聚于《DevOps 三十六计》一书,涵盖了产品设计、敏捷开发、微服务设计、持续集成和部署、自动化运维等整个DevOps 周期的各个关键环节。他山之石可以攻玉,相信大家可以从本书中学到不少DevOps 的实践。
——方国伟,平安科技CTO 兼总架构师
《DevOps 三十六计》涵盖了从需求到发布的整个软件生命周期,总共1000 多条计策,凝聚了一线互联网公司及通信行业、金融行业中的领头企业多年来的经验教训,实属难得。
——栗蔚,中国信息通信研究院云计算和大数据所云计算部副主任(主持工作),云计算开源产业联盟秘书长
《DevOps 三十六计》的创作者中有许多我熟悉的名字,他们都是在DevOps 界摸爬滚打多年的“老司机”,他们分享的三十六计可以说是对多年来走过的路、行过的桥、踩过的坑、跨过的坎的集中总结,其中有很多是要付出巨大的代价后才能感悟到的。相信无论你是DevOps 新兵还是老将,都能从《DevOps 三十六计》中获得一些感悟。
——刘栖铜,腾讯游戏助理总经理
“山不在高,有仙则名。水不在深,有龙则灵”。《DevOps 三十六计》一书系统地汇集了业界大咖多年的实战成果和经验,堪称DevOps 发展历史上的大事件。相信本书一定会给从业人员带来启发。
——胡罡,某世界500 强金融集团信息技术中心应用运行副总经理,复旦大学MSE 客座讲师
DevOps 是产品设计、开发、运维提升的必由之路,然而DevOps 的落地实施仍面临巨大挑战。《DevOps 三十六计》汇聚了众多专家的实践经验和切实感受,它的发布适逢其时,细读之必将受益良多。
——何勉,国内资深精益专家
《精益产品设计:原则、方法与实施》作者
《DevOps 三十六计》是中国互联网技术界的诚意之作,由来自BATJ等公司的大咖联袂撰写。作为这本书的总策划者,我深感本书字字珠玑、句句经典,很多计策背后都是血泪灌注的坑。熟读《DevOps三十六计》,少走几年弯路。
——萧田国,高效运维社区发起人
DevOps 时代社区发起人
第一章 精益
产品开发三十六计 何勉/ 2
总说/ 2
三十六计/ 4
案例:影响地图应用实例/ 8
更多案例
◎ 看板可视化方案设计实例
精益看板三十六计 李智桦/ 13
总说/ 13
三十六计/ 14
案例:看板的系统思维/ 16
更多案例
◎ 运用看板引导会议的进行
第二章 敏捷
大规模敏捷三十六计 赵卫/ 24
总说/ 24
三十六计/ 27
案例:大规模敏捷变革管理/ 31
更多案例
◎ 大规模敏捷组织结构
◎ 敏捷需求
◎ 敏捷架构
◎ 大规模敏捷运作
敏捷Scrum 三十六计 方炜/ 申健/ 38
总说/ 38
三十六计/ 40
案例:采用Scrum of Scrum 方式提升多团队间的协作/ 47
更多案例
◎ 关注专注力培养仪式感,提升Scrum 活动的效果
◎ 采用“观察—导向—决定—行动”方式持续解决问题,打造优秀的Scrum 团队
敏捷项目管理三十六计 杨晓俊/ 52
总说/ 52
三十六计/ 54
案例:现场客户/ 57
更多案例
◎ 需求评估点
◎ 站立晨会
Jira 三十六计 何英华/ 61
总说/ 61
三十六计/ 64
案例:Jira 对敏捷和精益的落地支撑/ 69
更多案例
◎ 测试管理利器:Zephyr 插件
第三章 持续交付
持续交付三十六计 张乐/ 石雪峰/ 77
总说/ 77
三十六计/ 79
案例:大型复杂产品的持续交付/ 83
更多案例
◎ Facebook 的分支策略演进助力持续交付
◎ Preflight 持续集成为质量保驾护航
◎ 大型团队推广持续集成
Git 应用三十六计 石雪峰/ 91
总说/ 91
三十六计/ 95
案例:多重体系保证版本控制系统的安全和高可用/ 99
更多案例
◎ 分支间快速差异对比和代码合并
◎ 保留历史记录,进行版本控制库拆分
Jenkins 三十六计 景韵/ 雷涛/ 李华强/ 104
总说/ 104
三十六计/ 106
案例:企业级Jenkins 之构建环境标准化、集群化、弹性化/ 109
更多案例
◎ 企业级Jenkins 之插件推荐列表
◎ 企业级Jenkins 之数据备份方案
◎ 企业级Jenkins 之精细化权限管理
◎ 企业级Jenkins 之精准化通知
◎ 乐视EUI 持续集成案例
Docker 应用三十六计 谭用/ 114
总说/ 114
三十六计/ 116
案例:优雅地停止容器/ 119
更多案例
◎ 给镜像瘦身
◎ 管好2375 端口
SaltStack 运维三十六计 赵舜东/ 123
总说/ 123
三十六计/ 126
案例:SaltStack 灵活的目标选择方式/ 130
更多案例
◎ YAML 编写技巧三板斧
◎ 使用salt-cloud 进行混合云管理
第四章 开发架构与运维开发
微服务架构三十六计 王磊/ 陈俊良/ 139
总说/ 139
三十六计/ 141
案例:微服务不只是拆拆拆/ 145
更多案例
◎ 微服务的轻量级测试
◎ 微服务创业的快与慢
Python 开发技巧三十六计 郭宏泽/ 152
总说/ 152
三十六计/ 154
案例:开发一个简单的监控平台/ 156
更多案例
◎ 如何选择Python 版本
◎ 自己动手实现运维平台
第五章 监控与质量测试技术
容量管理三十六计 梁定安/ 163
总说/ 163
三十六计/ 165
案例:容量木桶原理的应用/ 167
更多案例
◎ 架构前进一小步,容量提升一大步
◎ 结合“容量考核”合理使用运营成本
自动化测试三十六计 汪珺/ 171
总说/ 171
三十六计/ 176
案例:批量执行自动化测试的策略改进/ 179
更多案例
◎ 自动化测试思维的变化
◎ 无法适应变更的“死”自动化测试脚本
测试方法三十六计 徐奇琛/ 潘晓明/ 万千一/ 183
总说/ 183
三十六计/ 185
案例:统一化持续集成、持续交付,收归风险提升效率 / 190
更多案例
◎ 未覆盖最终版本带来的巨大风险
◎ 用JMeter 构建可靠廉价的压力测试方案
◎ 利用MAT 分析定位Android 内存泄漏问题
◎ UI 式样检测工具让测试人员拥有火眼金睛
◎ 运营活动监控系统为线上运营活动提供有力保障
第六章 安全技术
业务安全运维三十六计 邓冬瑞/ 196
总说/ 196
三十六计/ 199
案例:技术不是万能的,但是离开技术是万万不能的/ 201
更多案例
◎ 提高运营效率,快速响应,各司其职
◎ 要及时检视策略并做出相应调整,否则会殃及正常用户
安全测试三十六计 宗良/ 项阳/ 205
总说/ 205
三十六计/ 208
案例:有目的有计划的事前信息采集可以让安全
测试事半功倍/ 211
更多案例
◎ 没有考虑安全的设计就是没有防盗门的金库
◎ 仅仅发现问题,那是管杀不管埋
安全运维三十六计 韩方/ 216
总说/ 216
三十六计/ 217
案例:定期备份日志,还原入侵事件真相/ 221
更多案例
◎ 用多种认证手段提升安全防护等级
◎ 危险的匿名登录默认配置
第七章 大数据技术
数据质量三十六计 陈靖翔/ 226
总说/ 226
三十六计/ 229
案例:规范的企业主数据管理是数据质量的基石/ 233
更多案例
◎ 糟糕的数据处理架构会让数据异常处理付出更大的代价
◎ 精准的质量监控阈值会让运维工作更高效
大数据运维三十六计 范伦挺/ 236
总说/ 236
三十六计/ 238
案例:数据驱动精细化运维/ 241
更多案例
◎ 欲速则不达——直接删除惹的祸
◎ 数据驱动智能运维
◎ 离线作业监控平台的应用
第八章 日常运维
日常运维三十六计 梁定安/ 246
总说/ 246
三十六计/ 248
案例:从源头优化运维工作/ 250
更多案例
◎ 演习,为容灾策略保鲜
◎ 重点关注与保障不可逆操作的质量
Linux shell 三十六计 阿铭/ 254
总说/ 254
三十六计/ 255
案例:根据网卡名字输出对应的IP 地址/ 259
更多案例
◎ 自动封/ 解封IP
◎ 监控httpd 进程
◎ 备份数据库
◎ 监控磁盘使用
◎ 构建一个发布系统
网络运维三十六计 张永福/ 265
总说/ 265
三十六计/ 267
案例:利用自动化运维工具提升工作效率/ 270
更多案例
◎ 在网络排障中锻炼“抽丝剥茧”的能力
◎ 网络运维过程中团队合作的重要性
分布式存储运维三十六计 高向冉/ 275
总说/ 275
三十六计/ 277
案例:不及时回收删除的文件引发的成本问题/ 280
更多案例
◎ 微信存储应对节假日大规模突发事件
◎ 定期进行单点剔除演习的重要性
◎ 现网一定要干干净净
第九章 自动化运维
自动化运维三十六计 胥峰/ 285
总说/ 285
三十六计/ 286
案例:建设自动化运维体系/ 289
CMDB 三十六计 王津银/ 303
总说/ 303
三十六计/ 306
案例:应用CMDB 支撑更多的核心场景/ 309
更多案例
◎ 每个成功的CMDB 都离不开全员参与
◎ 面向新IT 的CMDB 模型管理新思路
第十章 运维管理
运维管理三十六计 涂彦/ 315
总说/ 315
三十六计/ 317
案例:运筹帷幄,解密远程管理/ 321
更多案例
◎ 运维管理者如何与年轻员工打成一片
◎ 用互联网产品思维管理远程团队
轻量ITSM 三十六计 闫林/ 328
总说/ 328
三十六计/ 332
案例:某大型银行大面积业务中断故障/ 338
更多案例
◎ 从5 万个网站宕机谈起
◎ 从2008 年北京奥运售票系统的崩溃谈起
第十一章 数据库运维
互联网数据库运维三十六计 周小军/ 341
总说/ 341
三十六计/ 342
案例:优化热记录与肥胖记录/ 344
更多案例
◎ 未经测试的数据搬迁工具引发的故障
◎ 节假日前的数据库容量规划
MongoDB 运维三十六计 周李洋/ 349
总说/ 349
三十六计/ 351
案例:MongoDB 执行计划分析——知其所以然/ 355
更多案例
◎ 由于滥用Schema less 导致的运营事故——Schema less 而非Schema free
◎ 提前排兵布阵,减少阵型调整带来的损耗——Sharding 架构下预分片
Oracle 运维三十六计 盖国强/ 361
总说/ 361
三十六计/ 363
案例:禁止远程DDL 和业务时间的DDL 操作/ 368
更多案例
◎ 有效的备份重于一切
◎ 测试和生产环境隔离
PostgreSQL 运维三十六计 周正中/ 375
总说/ 375
三十六计/ 377
案例:菜鸟末端轨迹项目中的面面判断/ 381
更多案例
◎ 共享充电宝实时经营分析系统的后台数据库设计
第十二章 数据中心运维
CDN 运维三十六计 高向冉/ 396
总说/ 396
三十六计/ 398
案例:应对CDN 各层级网络问题/ 400
更多案例
◎ NBA 直播总决赛突发场景应对
◎ 机房网络异常下的快速处理机制
数据中心运维节能三十六计 闫林/ 405
总说/ 405
三十六计/ 407
案例:某IT 企业高能耗大型数据中心的分析与改善/ 411
更多案例
◎ 某石化企业高能耗大型数据中心的分析与改善
◎ 某互联网公司大型数据中心的节能环保措施
IDC 运维三十六计 王莹/ 414
总说/ 414
三十六计/ 415
案例:inode 引发的业务中断/ 418
更多案例
◎ SAN 存储故障
◎ SAN 架构调整
致谢/ 423
DevOps 是Development(开发)和Operation(运维)两个单词的缩写。DevOps 这个词是Patrick Debois 于2009 年创造的。出生于比利时的Patrick 先生曾经是一名苦闷的IT 咨询师,饱受开发和运维相互割裂及伤害之苦。2009 年他参加了一个技术大会,在会上听了名为10+ Deploys Per Day: Dev and Ops Cooperation at Flickr 的演讲,深受启发,并创造了DevOps 这个词。从那以后,Patrick 先生身体力行,在全球范围内不遗余力地推广DevOps,是公认的DevOps 之父。
2017 年3 月,在各种机缘巧合之下,我有幸和朋友们一起邀请Patrick 先生来北京做深度交流,在深深感动之余,作为一名运维行业的老兵,一名同样饱受运维开发割裂之苦的老兵,我也更坚定了在国内推广DevOps 的决心与信心。这正是我和张乐、景韵、石雪峰和雷涛等朋友成立DevOps 时代社区的初衷。
诚如一位朋友所言,DevOps 发展到今天,早就不是开发和运维之间的简单“暧昧”。目前国际上公认的DevOps 以自动化为基础,以合作文化为黏合剂,以业务目标为己任,从计划、需求、设计到开发、测试、部署、运维及运营,贯穿于软件的整个生命周期。DevOps 源于技术,但又超出技术。衡量一个企业实施DevOps 是否成功的标准在于,是否提高了企业的营收、利润及市场占有率。
令人苦恼的是,DevOps 本质上是一组最佳实践,因需而变,就像水一样,很难固化。这使得 DevOps 的落地十分困难,中小企业,特别是传统行业中的中小企业更是感觉茫茫然无从下手。
基于此,DevOps 时代社区和高效运维社区联合国内外DevOps 专家发布了DevOps 道、法、术、器,以融合国外及国内顶尖互联网企业的经验和智慧结晶,并给出指导思想及立体化实施框架,如下图所示。
道,即“快速交付价值,灵活响应变化”,这是指导思想,需要用法、术、器来实现。
法,即“全局打通敏捷开发 & 高效运维”,我们用“研发运营一体化(DevOps)能力成熟度模型”来承载,按照国内的通用说法,能力成熟度模型也是标准的一种,因此也可以称为DevOps 标准。该标准体系涵盖了过程(敏捷开发、持续交付、技术运营)、应用设计、安全管理及组织结构,已在工信部相关部门正式立项,由云计算开源产业联盟(OSCAR联盟)和社区牵头,组织相关互联网、金融、电信等领域专家联合撰写,将于2018 年完成征求意见稿,并将进行针对企业DevOps 能力的试评估。
术,我们用《DevOps 三十六计》来承载,也就是本书。《DevOps三十六计》可不仅仅只有36 计哦,共有36 篇文章,1349 条计策,115个案例,涵盖精益、敏捷、开发、测试、运维、架构、安全等方面的内容。本书历时一年多,由40 名国内外大咖联合编写,并进行交叉审核。原本所有的案例都保留在书中,但总篇幅达到了700 多页,考虑到定价太高,我们只好忍痛割爱,每篇文章仅保留一个案例,其余案例发布在网站上,并在每篇文章中给出了对应的二维码入口,读者可以很方便地阅读之,也可以在那里与作者交流讨论。
可以说《DevOps 三十六计》中的很多计策都是血泪史,都是大厂们用惨痛的代价换来的。本次汇集出版旨在总结经验和交流共享,让国内互联网及传统企业不再重复踩坑,少走一些弯路。
本书涉及面广而深,难免有计策或内容有纰漏,还请读者们不吝指出。关于本书的相关讨论及修正,请访问高维在线网站(http://www.gaowei.vip),我们将邀请给出真知灼见、金玉良言的您,出现在本书再版时的致谢页面,聊表谢意。
萧田国
《DevOps 三十六计》主编
DevOps 时代社区和高效运维社区发起人
我必须强调这本书的“辩证法”思想。在DevOps的世界里,我们常常被教导“要快,所以要自动化一切”,但这往往忽略了在某些特定场景下,过度的自动化反而会成为创新的枷锁。这本书中有一个章节专门讨论了在创新孵化阶段如何保持“适度的手动干预”和“快速反馈回路”的平衡,这在很多教材中是看不到的。它承认DevOps并非万能药,而是需要根据业务的成熟度和风险偏好进行定制化的调整。例如,在新产品A/B测试阶段,我们应保持高频、小批量的快速迭代;而在核心交易系统升级时,则应侧重于更严格的流程控制和更深度的审计。这种务实、不走极端的态度,让我对DevOps的理解更加成熟和全面。它鼓励读者像一个军事家一样,根据战场环境来选择最合适的战术,而不是生搬硬套任何一种固定的范式。这本书是实践者面对复杂现实世界时,最可靠的参谋手册。
评分这本书的结构设计非常巧妙,它不是线性的,更像是一个知识地图,允许读者根据自己的痛点自由跳转。我最开始翻阅时,直接跳到了关于“可观测性”的那几章。现在的系统日志、指标和追踪数据量大到令人望而却步,如何从中快速定位问题的根源是每个运维团队的噩梦。书中对分布式追踪的引入和实践,结合OpenTelemetry的框架,提供了一个非常清晰的路径图,如何从“日志海洋”中捞出关键信息。它不仅讲了收集,更深入探讨了如何构建高效的仪表盘和警报策略,确保告警是可行动的(Actionable),而不是无休止的“噪音”。这让我重新审视了我们现有的监控体系——很多警报其实只是症状而不是病因。通过书中提到的“四黄金信号”分析方法,我们成功地将无效警报数量减少了近三分之二,团队终于能把精力集中在真正影响用户体验的问题上。对于正在经历系统规模爆发性增长的团队而言,这本书提供的可观测性战略是不可或缺的。
评分说实话,我原本对这类技术书籍抱持着一种审慎的态度,因为太多工具指南读起来枯燥乏味,而且信息更新迭代太快,等你看完可能里面的技术栈都过时了。然而,这本书的视角非常独特,它把DevOps的实践过程比作一场精心策划的战役,用“计”来命名各个章节,这种叙事方式极大地增强了阅读的代入感和趣味性。我尤其欣赏它在“文化重塑”方面的着墨。很多技术人员忽略了人与人之间的协作才是DevOps成功的基石。书中详细阐述了如何打破开发、测试和运维之间的“筒仓效应”,通过设立共享目标和激励机制来促进跨职能团队的紧密合作。我发现我们团队内部的沟通效率明显提高了,以前互相推诿责任的现象少了,取而代之的是一种“我们共同的敌人是Bug和低效流程”的心态。这本书没有给我一堆复杂的代码示例,而是提供了一套思维框架,这比任何具体的脚本都更具价值和持久性。它让我意识到,我们需要的不仅仅是CI/CD管道,更需要一套能够让组织高效运转的“内功心法”。
评分这本书简直是为我这种在企业级环境中摸爬滚打多年的老兵量身定制的。我以前总觉得DevOps是一套模糊的哲学,落地的时候各种工具链七零八落,大家都在说要自动化、要快速迭代,但真到关键时刻,总有流程上的瓶颈卡住。这本书的厉害之处在于,它没有停留在高谈阔论的“敏捷转型”上,而是像一本武功秘籍,将实战中遇到的那些硬骨头问题一一拆解,然后给出了一套套可操作的“计策”。比如,关于如何处理遗留系统和微服务架构的并行演进,书中给出的那种渐进式的改造方案,简直是醍醐灌顶。我印象特别深的是关于“灰度发布”的那一章节,它描述了如何利用Canary部署和蓝绿部署的组合拳来规避重大风险,并且还结合了SRE的最佳实践来监控关键业务指标。读完后,我立刻组织团队,将我们之前那种“All-in”式的发布策略调整了过来,效果立竿见影,部署成功率提升了近20%,而且关键业务中断时间几乎为零。这不光是技术上的提升,更是管理思维上的转变。它教会我,DevOps不是一次性的项目,而是一系列需要不断演进的战略布局。
评分作为一个专注于云原生基础设施的架构师,我一直都在寻找那种能够将Kubernetes、服务网格和GitOps理念融会贯通的深度指南。这本书在这方面做得非常出色。它没有简单罗列这些技术的特性,而是将它们嵌入到一个完整的、端到端的交付流程中进行论述。让我眼前一亮的是它对于“配置漂移”问题的处理,书中提出的基于策略即代码(Policy as Code)的治理模型,彻底改变了我过去手动检查集群状态的做法。通过引入像OPA(Open Policy Agent)这样的工具,实现了对环境一致性的自动化保障,这在多租户或合规性要求高的场景下简直是救命稻草。读完这部分内容后,我们立即着手重构了我们的部署校验逻辑,将原本需要人工介入的合规性检查完全纳入了Git仓库的版本控制中。这种从“被动修复”到“主动预防”的转变,极大地降低了因人为失误导致的生产事故风险,可以说是技术深度和实战价值完美结合的典范。
评分没有实质性技术分析,只是策略上提供参考。比较笼统,像文艺书的感觉
评分东西非常不错呀,值得购买
评分一般般这本书
评分书里面把运维过程中可能碰到的坑都点出来了,值得好好研读,深入体会,想给部门里的同事一人发一本。
评分一般吧
评分不错不错,性价比高,推荐购买!
评分还没看!!
评分活动买的,质量可靠,价格实惠
评分一般般这本书
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.idnshop.cc All Rights Reserved. 静思书屋 版权所有