当前位置:主页 > 计算机电子书 > 程序设计 > DevOps下载
DevOps三十六计

DevOps三十六计 PDF 原书完整版

  • 更新:2019-05-21
  • 大小:155.8 MB
  • 类别:DevOps
  • 作者:DevOps时代社区
  • 出版:电子工业出版社
  • 格式:PDF

  • 资源介绍
  • 相关推荐

DevOps三十六计

DevOps三十六计

读者评价

新型的DevOps涵括了从需求提出到软件发布的整个软件生命周期,是产品设计、项目管理、开发、测试和运维提升的必由之路,国内大型互联网企业已经做了很多探索,并将相关技能规范化、文档化、工具化、自动化甚至智能化。
当年作为第一波加入高校运维社区的人,对本书期待了挺久的,DevOps涉及的方方面面,国内发展得如火如荼,看完再来评价。书厚度中等,浓缩即精华,互联网一线的经验教训和代价总结分享,推荐一读。

内容介绍

新型的DevOps涵括了从需求提出到软件发布的整个软件生命周期,是产品设计、项目管理、开发、测试和运维提升的必由之路,国内大型互联网企业已经做了很多探索,并将相关技能规范化、文档化、工具化、自动化甚至智能化。遗憾的是,这些宝贵经验往往仅在团队或公司内部分享,很多中小公司还在重复走着大公司走过的弯路。为了促进先进经验在整个行业内分享和传播,DevOps时代社区和高效运维社区邀请了40位业界大咖,从精益、敏捷、开发、测试、运维、架构、安全等各个方面分享他们在Top互联网公司及领先的传统企业的多年智慧和经验结晶。本书共有36篇文章,1349条计策,其中很多计策都是在经历了刻骨铭心的事故后总结出来的,精选的115个案例则是对相关计策的解读。本书旨在总结经验、交流共享,让国内互联网及传统企业缩短成长路径、避免无谓的反复踩坑,让技术人员更好地聚焦于业务目标和业务产出。本书主编为萧田国和梁定安,欢迎提出宝贵意见和建议。

目录

  • 第一章 精益
  • 产品开发三十六计 何勉/ 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

资源下载

资源下载地址1:https://pan.baidu.com/s/1zKwkg_rB2Bnp2O5-JG7-MA

网友留言

网友NO.33586
贺密如

通过对DevOps进行一段时间的学习,对自己负责的测试模块有了一点点自己的小想法。通过对整个研发流程的重新认识和理解,思考测试在整个研发流程中扮演的角色,应该做的主要工作,以及涉及到的影响因素进行思考。最后思考对测试管理、数据管理主要做的具体工作是什么,通过怎样的方式,来保证研发质量。 对于测试主要工作,在当前CI/CD下应该怎么有效的进行,在后面将进行持续的学习和思考。 整个研发体系是按照DevOps的方式进行,service mesh 能够提高研发的效率,让研发关注业务本身,解决微服务带来的服务上下游关系、路由、监控、动态配置……,一系列研发功能时需要考虑的问题。 通过分享知道对于DevOps的研发过程,应该在持续交付的过程中,做好测试管理、数据管理。 为了保证测试管理和数据管理更好的执行,涉及到配置管理、构建与持续集成、部署与发布管理、环境管理、度量与反馈。

网友NO.37618
贺水格

DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。[1]外文名DevOps全称 Development和Operations的组合优点尽可能地自动化用途协作与整合等。 以上内容来自百度百科。 在我看来: 1.主要就是为了整合资源,使资源充分利用.让开发人员像使用水电一样的使用资源,让开发人员聚焦在更有价值的事情身上,让整个开发阶段中不同的工具串联在一起,形成一条完整的流水线。 2.可视化可跟踪,通过一系列的工具可以对开发需求进行持续的跟踪,很明确的且客观看到任务的当前状态,而且出了问题之后可以追溯,让你能精准的定位到哪个环节出现了问题。 3. 在运维方面,尽可能的通过监控工具,收集数据,通过大数据,深度学习等手段,来解放运维人员,而且数据不断的可视化,也有利于实时监控(其实我没做过运维,在这方面理解得比较浅,慢慢好好学习吧)