《DevOps三十六计》| 每日读本书

简介: 40位DevOps专家联袂打造,全面覆盖精益、敏捷、开发、运维、测试等领域。每日搜罗最具权威专业书籍,更多图书请关注“每日读本书”。

编辑推荐

DevOps时代社区与高效运维社区倾情奉献
40位DevOps专家联袂打造
1349条计策凝聚经验与智慧

test

内容提要

新型的DevOps 涵盖了从需求提出到软件发布的整个软件生命周期,是产品设计、项目管理、开发、测试和运维提升的必由之路,国内大型互联网企业已经做了很多探索,并将相关技能规范化、文档化、工具化、自动化甚至智能化。遗憾的是,这些宝贵经验往往仅在团队或公司内部分享,很多中小公司还在重复走着大公司走过的弯路。

为了促进先进经验在整个行业内分享和传播,DevOps 时代社区和高效运维社区邀请了40 位业界大咖,从精益、敏捷、开发、测试、运维、架构、安全等各个方面分享他们在顶级互联网公司及领先的传统企业的多年智慧和经验结晶。《DevOps三十六计》共有36篇文章,1349 条计策,其中很多计策都是在经历了刻骨铭心的事故后总结出来的,配套的115 个案例则是精选的、对相关计策的解读。

《DevOps三十六计》旨在总结经验、交流共享,让国内互联网及传统企业缩短成长路径、避免无谓的反复踩坑,让技术人员更好地聚焦于业务目标和业务产出。

《DevOps三十六计》主编为萧田国和梁定安,欢迎提出宝贵意见和建议。

精彩导读

前言

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实践指南(二十四)| 智能运维
智能运维( AIOps )是依托于阿里巴巴 DevOps 经验沉淀而来的智能化运维平台,通过运维大数据的积累,以及算法团队多种算法的校对,我们将运维提升到新的高度,通过 AI 来帮我们查看数据、判断异常、决策运维操作,形成监、管、控一体化的运维平台。
阿里巴巴DevOps实践指南(二十四)| 智能运维
|
运维 监控 安全
阿里巴巴DevOps实践指南(十五)| 应用环境能力
应用环境解决方案并不仅仅是将应用的开发环境、基础环境搭建起来即可,还涉及到环境的稳定性如何保证,基于环境如何规范变更的流程,基于环境如何提升开发效率等等。环境治理需要站在更高的角度,综合看待上述问题,否则就会陷入环境问题年年治理、年年被吐槽的怪圈。
阿里巴巴DevOps实践指南(十五)| 应用环境能力
|
敏捷开发 监控 容灾
阿里巴巴DevOps实践指南(二十二)| 发布策略
DevOps 追求更短的迭代周期、更高频的发布。但发布的次数越多,引入故障的可能性就越大。更多的故障将会降低服务的可用性,进而影响到客户体验。所以,为了保证服务质量,守好发布这个最后一道关,阿里逐步发展出了适应 DevOps 要求的发布策略。
阿里巴巴DevOps实践指南(二十二)| 发布策略
|
运维 Devops Java
阿里巴巴DevOps实践指南(十三)| 测试提效
分布式测试为测试速度插上了翅膀,精准测试有效的识别出了测试的范围,增量覆盖率又为测试的不断完备提供了有利的指引,线上覆盖率帮助我们有效的进行应用瘦身。充分利用好这些技术手段进行测试提效,可以让持续交付的过程更加的顺畅
阿里巴巴DevOps实践指南(十三)| 测试提效
|
5月前
|
运维 Devops jenkins
十六年所思所感,聊聊这些年我所经历的 DevOps 系统
从 2008 年开始,我陆陆续续参与了多个 DevOps 系统的建设,如今,审视这些系统的建设初衷和它们的设计思路或遇到的问题,依然有不少借鉴意义。我会按照时间顺序,把每个 DevOps 系统的特点,诞生的背景,以及在当时所主要解决的问题做一个概要的介绍,同时,我们也会以今天的视角再次审视这些问题,来看下同样的问题,经过十几年的发展,解决方案上有哪些不同。
|
运维 监控 Devops
【运维杂谈】DevOps是什么意思?
【运维杂谈】DevOps是什么意思?
497 0
|
Devops 测试技术 持续交付
阿里巴巴DevOps实践指南(五)| 业务驱动的协作
明确需求层次以及每个层次承载的价值之后,接下来要做的是定义每个层次的协作过程,最终服务于“顺畅高质量地交付业务需求”这一目标。如何组织各个层次的协作,来达成这一最终目标?
阿里巴巴DevOps实践指南(五)| 业务驱动的协作
|
敏捷开发 运维 Kubernetes
|
Cloud Native Devops
2022 阿里云研发效能峰会来啦,云原生 DevOps 分论坛抢先看
2022 阿里云研发效能峰会来啦,云原生 DevOps 分论坛抢先看
2022 阿里云研发效能峰会来啦,云原生 DevOps 分论坛抢先看
|
缓存 资源调度 Java
阿里巴巴DevOps实践指南(十七)| 提升构建的效率
构建是将源码变成制品的过程。构建包括编译,但不等同于编译。即使对于不需要编译的解释型语言,也要构建成一个压缩包或 Docker 镜像再去部署。无论是在开发阶段还是 CICD 阶段,都离不开构建过程,构建的质量和效率对持续交付影响很大。影响构建效率的因素,包括源码以及构建的依赖。
阿里巴巴DevOps实践指南(十七)| 提升构建的效率