共计 5934 个字符，预计需要花费 15 分钟才能阅读完成。
源于读了《凤凰我的项目: 一个 IT 运维的传奇故事》一书（感激徐磊同学的举荐），这本小说体零打碎敲的书，浏览感触十分好，提笔想做读书笔记却有些犯难，小说貌似只有写读后感的；恰好随后给共事做过两次 DevOps 的介绍，伺机整顿了一下思路，将本人对 DevOps 方方面面的了解，最终出现为这篇文档，作为阶段性的总结。
什么是 DevOps？
- DevOps 不只是开发与运维的问题
- 从大处着眼
- 从小处下手
- 通过加大部署 / 公布频度来撬动整个交付过程
- 自动化、标准化、配置化
- DevOps 实际
- DevOps 与云
- DevOps 与精益、麻利
- 三步工作法
一、以下问题有没有解？
- “疾速将产品推向市场”与“提供稳固、平安并牢靠的 IT 服务”是否能够兼得？
- 用更少的资源实现更多的业绩，既要放弃竞争力，又要削减老本；
- 如何解决工作交接呈现的问题，例如业务与开发，开发与运维之间；
- 运维人员是否和其他人一样，失常上下班，而不必在夜里或者周末加班？
二、什么是 DevOps？七嘴八舌
WikiPedia 上说：”DevOps 是软件开发、运维和质量保证三个部门之间的沟通、合作和集成所采纳的流程、办法和体系的一个汇合。它是人们为了及时生产软件产品或服务，以满足某个业务指标，对开发与运维之间相互依存关系的一种新的了解。“
百度百科说：“DevOps（英文 Development 和 Operations 的组合）是一组过程、办法与零碎的统称，用于促成开发（应用程序 / 软件工程）、技术经营 和品质保障（QA）部门之间的沟通、合作与整合。它的呈现是因为软件行业日益清晰地意识到：为了按时交付软件产品和服务，开发和经营工作必须严密单干。”
IBM 这样说：DevOps 是企业必备的继续交付能力，通过软件驱动的翻新，保障组织抓住市场机会，同时缩小反馈到客户的工夫。
三、DevOps 不只是开发与运维的问题
一般而言，开发与运维有着不同的文化；开发部门的驱动力通常是“频繁交付新个性”，而运维部门则更关注 IT 服务的可靠性和 IT 老本投入的效率，升高危险。两者指标的不匹配，在开发与运维部门之间造成了鸿沟，从而减慢了 IT 交付业务价值的速度。运维从维稳登程，天然心愿生产零碎部署上线次数越少越好，而上线频度升高，对开发人员是一个负激励：反正我公布的版本也不会上线，反正我再踊跃也不能实时的体现进去，团队积极性和人员士气都会受到打击。
与此同时，业务部门则心愿业务需要尽快的推向市场，而维稳的要求导致价值交付用户的速度被延缓，价值无奈迅速失去反馈验证。
当公布列车变成 3 个月一趟车次时，业务人员习惯于本人的需要无奈疾速失去满足，能想出的的办法就是把所有的业务需要都设置成最高优先级，去抢占公布窗口。所有人都这样想这样做，拥挤就此产生，真正高价值的需要无奈失去疾速交付。（试想，如果每天有十次公布，大家还会拼得头破血流去抢一个公布窗口么？）
上线频度低的另一个副作用是，单次上线中蕴含的变更规模变大，危险也随之减少。事实上，缩小上线次数不仅不会升高危险，反而让每一次上线都变得像一个火药桶，危机四伏。
四、从大处着眼
究其基本，DevOps 目标是晋升业务交付能力：如何疾速的交付想法；如何让客户进行尝试（从而获取反馈）；如何疾速响应客户反馈；
DevOps 不应该只是 IT 外部的几个部门玩的游戏。必须跳出 IT 的角度，端到端（业务端到客户端）剖析，能力弄清公司须要依附 IT 的哪些工作来撑持业务指标，撑持企业策略，从而实现更残缺、真正的 DevOps。
须要将 IT 变成一种能力，融入公司的日常运作中，融入业务流动中。在快鱼吃慢鱼的时代，须要疾速试错，一直整合来自市场的反馈。
所以最终，DevOps 是一个端到端的问题，是产品管理部、开发部、测试部、IT 运维部、信息安全部协同工作，独特反对。
DevOps 尝试建设一个业务价值交付管道，业务布局、需要梳理、打算、开发、构建、测试、部署、运维、监控，在此交付过程中波及到的部门 / 团队、过程、零碎、办法都归属于 DevOps 关怀的内容。
五、从小处下手
了解了 DevOps 是一个端到端的过程，整个交付链条波及太多的畛域，问题也层出不穷，无从下嘴。实际操作中，须要有一个切入点。
DevOps 的思维以精益与麻利为外围，通过裸露问题，解决问题，从而实现继续改良。从精益的角度看，在代码投产之前，实际上未产生任何价值，都只是半成品。要限度半成品，即在制品（WIP）数量，让其尽快流过生产线，让投入产生交付价值。
DevOps 是一个简单问题，咱们却心愿能够把一个简单的问题简单化：正如装修时通过加压查看管道是否泄露，是否有阻塞；咱们也通过加压的形式来裸露软件交付管道的问题。
如何加压？以终为始，咱们抉择业务价值交付的那个点，也就是部署与公布来对整个交付管道进行加压。
能够简略的问本人一个问题：“能不能一天部署 10 次？”如果没有方法？那么起因何在？流程不标准？自动化不够？沟通导致效率低下？过程无奈复用？环境差别导致回归出错？逐个的裸露问题，解决问题，交付能力天然晋升。
须要留神的是，依据《凤凰我的项目》中提到的 TOC 束缚实践（Theory of Constraints），在瓶颈之外的任何中央做出的改良都是假象，在瓶颈之后做的任何改良都是徒劳的，因为只能干等着瓶颈把工作传送过去，而在瓶颈之前做的任何改良则只会导致瓶颈处沉积更多的库存。所以如何辨认真正的瓶颈变得尤为重要，在发现问题之后多问几个为什么，力求找到本源起因。
DevOps 的由来
Flickr 公司的约翰. 阿尔斯帕瓦和保罗. 哈蒙德在 2009 年 Velocity 技术大会对于开发速率的一场演讲，“一天十次部署”，是 2009 年前后衰亡的 DevOps 静止的一部分，提倡开发和 IT 运维通力协作，在实现高频率部署的同时，进步生产环境的可靠性、稳定性、灵敏性和安全性。2009 年一天十次部署就算很快了，但当初只能算平均水平，2012 年亚马逊公司发表，他们均匀每天能发展 23000 个部署。
Wikipedia 上说，有以下几方面因素可能促使一个组织引入 DevOps：
- 应用麻利或其余软件开发过程与办法
- 业务负责人要求放慢产品交付的速率（新兴技术趋势，例如云计算、挪动利用、大数据和社交媒体）
- 虚拟化和云计算基础设施（可能来自外部或内部供应商）日益广泛
- 数据中心自动化技术和配置管 理工具的遍及
- 传统的治理形式导致“烟囱式自动化”，从而造成开发与运维之间的鸿沟
六、通过加大部署 / 公布频度来撬动整个交付过程
以利用部署自动化作为切入点，由部署自动化，往前倒逼测试自动化、构建自动化；进一步往前，配置管理、变更治理是根底要求；再往前，业务需要与麻利打算同步关联，通过短周期迭代交付与反馈，增强业务与开发的合作沟通；
同样的，往后端与运维连接，更小、更频繁的变更，须要让开发人员更多地管制生产环境，更多地以应用程序为核心来了解基础设施；须要定义简洁明了的流程，尽可能地自动化；从而在实现高频率部署的同时，进步生产环境的可适应性，与此同时，可靠性、稳定性、弹性和安全性也同时晋升；
由此也促成了开发与运维的合作，通过一直缩减批量规模，实现疾速工作流，确保了部署环境时刻准备就绪，按需投产。频繁的公布、意味着每次公布蕴含的变动更少，每次部署不会对生产零碎造成微小影响，应用程序会以平滑的速率逐步成长。逐渐协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。
七、DevOps 要实现：自动化、标准化、配置化
- 自动化：全面自动化，构建、部署、测试、降级、扩大、保护、数据卫生、监测、平安和策略管理。通过自动化，倒逼团队高效沟通，倒逼流程标准；自动化伎俩确保部署工作的可重复性、缩小部署出错的可能性。
- 标准化：（流程，环境，配置）根底环境标准化，运行环境标准化，应用环境标准化 / 多样化；
- 配置化：通过配置，尽量避免代码，通过性能开关或者参数设置，来反对 A /B testing、灰度公布；
八、DevOps 实际
- 不做什么比做什么更重要：相比起向零碎中投入更多的工作，将无用的工作剔出零碎更为重要；无用的工作，无用的我的项目，无用的产品；排优先级，哪些是重要的工作；
- 运维参加研发评审：常见的景象是，运维人员很少被邀请参加架构决策或代码评审，开发代码是否会影响运维环境后期无人知晓，须要让运维人员参加架构评审，从运维角度提出对系统的要求；
- 非功能性需要同样重要：偿还技术上的债权。每个人都像器重功能性要求一样器重非功能性要求 QoS（品质，稳定性，可维护性，持续性，可扩展性，可管理性，安全性，可操作性），非功能性需要对于实现业务指标等同重要。要把非功能性需要设计到产品当中。
- 整体合作：产品所有者，开发部，QA，IT 运维部以及信息安全部通力协作，帮忙彼此乃至整个企业取得胜利。
- 品质为先：上游团队不再给上游团队造成麻烦，开发部将 20% 的工夫用于帮忙确保工作顺利的通过整个价值流，放慢自动化测试，改良部署基础架构，并确保所有应用程序建设有用的产品遥测；
- 基础架构即代码（Infrastructure as a Code）：把创立和部署流程自动化，把基础架构当成代码一样看待；各套环境之间，代码版本、运行时、环境配置须要匹配；须要将根底环境配置化、版本化治理；
- 运维服务化：DevOps 会让开发部门承当更多的代码部署和维持服务水平的责任。要求把许多 IT 运维工作转变为自助服务。
- 版本化所有（Versionlize Everything）：应该把所有货色都进行版本控制，不只是代码，而是创立环境所需的每一样货色。
- ITIL：为了适应 DevOps 更短的交付周期和更高的部署频率，ITIL 流程的很多方面都须要自动化，特地是变更、配置和公布流程等。
- 云计算：无效的利用云技术，能够为开发和测试人员动静设置基础架构资源，疾速取得测试环境；
- 针对类生产零碎进行开发和测试（环境的标准化），利用可反复的牢靠流程进行部署，监控并验证运维品质；
- 放大反馈回路：疾速反馈回路，避免问题代码进入生产环节，并且让代码可能迅速部署投产，从而迅速发现并修复任何产品问题。（编写代码时，单元测试、集成测试、验收测试始终在类生产环境运行，一直确认，代码和环境奖会依照事后设定的运行，并且总是处于可部署状态）
九、DevOps 与云
DevOps 要反对云，虚拟化与云技术能够带来 DevOps 要求的标准化以及自动化；
环境标准化，无论是基础设施还是运行时环境，并把这些环境投入开发、QA 和 IT 运维的日常应用，就能打消大部分在部署流程中因为差别而导致的问题。不仅应该拿出可部署的代码，还应该领有部署这些代码的确切环境，并在版本控制中一并管制与查看。
混合云下的 DevOps 诉求：在云的场景下，如何利用虚拟化、容器等减速环境的创立以及标准化，如何通过自动化的形式放慢环境搭建；如何在 On-Prem、公有云、私有云，不同厂商不同类型的云的混合模式下，对立流程，对立 DevOps 的用户感触；
同时，由应用层的自动化部署，同样能够发现 Infrastructure 层, Runtime 层的问题，虚拟化与云的技术也与 DevOps 相辅相成，井水不犯河水。
十、DevOps 与精益、麻利
DevOps 是基于麻利与精益准则的办法。DevOps 是软件开发生命周期（SDLC）从瀑布式到麻利再到精益的倒退。
DevOps 超过了麻利，它的关注点是从 SDLC 中移除节约。通常状况下，发现节约或者瓶颈的模式包含：不统一的环境，人工的构建和部署流程，差的品质，IT 部门之间短少沟通和了解，频繁的中断和期待，局部实现的工作，额定的性能，工作切换等。
DevOps 强调流水线，交付管道，与传统生产与制造业有着千头万绪的分割；而《凤凰我的项目》一书中间接用生产工厂来点化故事的主人公，与 IT 开发运维间接类比；
DevOps 施行中，能够借鉴精益实践中的很多思维，例如：升高批量规模、缩小半成品、缩短并加强反馈回路、价值流图剖析、工夫线剖析、打消节约，以及麻利中继续集成、继续测试、继续交付、继续监控、A/ B 测试、灰度公布、滚动更新等。
十一、三步工作法
《凤凰我的项目: 一个 IT 运维的传奇故事》中倡议的三步工作法以实现 DevOps：
- 第一工作法：（帮忙了解在工作从开发移向 IT 运维时该如何建设疾速工作流）从开发到 IT 运维再到客户的整个自左向右的工作流。为了使流量最大化，须要小的批量规模和工作距离，绝不让缺点流向上游工作重心，并且一直为了整体指标（绝对于开发性能完成度、测试发现 / 修复比率或运维有效性等部分指标）进行优化。必要的做法：看板、继续构建、集成以及部署，按需创立环境，严控半成品，以及构建起可能顺利变更的平安零碎和组织。
- 第二工作法：（如何缩短以及放大反馈环路，从而在源头解决品质问题）价值流各阶段自右向左的疾速继续反馈流，放大其效益以确保防治问题再次发生，或者更快的发现和修复问题。这样咱们就能在所需收入获取或潜入常识，从源头上保证质量。必要的做法：在部署管道中的构建和测试失败时“进行生产线”；日复一日的继续改良日常工作；创立疾速的自动化测试套装软件，以确保代码总是处于可部署的状态；在开发和 IT 运维之间建设独特的指标和独特解决问题的机制；建设广泛的产品遥测技术，让每个人都晓得，代码和环境是否在依照设定运行，以及是否达到了客户的指标。
- 第三工作法：（如何建设文化，技能激励碳酸，从失败中吸取教训，又能了解重复的工夫是精通工作的先决条件）发明公司文化，带动两种风尚的造成：一直创世，这须要承担风险并从胜利和失败中吸取经验教训；了解反复和练习是熟练掌握的前提。一直加压，从而强化习惯并加以改进。（零碎里要常常出些故障，长此以往，再遇到困难就没原来那么苦楚了）必要的做法：营造一种勇于创新、敢于保险以及高信任度的文化，把至多 20% 的开发和 IT 运维周期布局给非功能性需要，并一直激励进行改良。
十二、KPI 与度量
为了促成 DevOps 策略，调整绩效考核和激励机制是必要的，本来按各自为政的 KPI 考核只会造成部门之间的隔膜，仍然只依据敲出代码的生产力来处分开发人员，或者依据基础设施的可靠性来处分运维人员，什么都无奈扭转；围绕业务零碎而不是职责来组织工作，这就是 DevOps 突破 IT 分组壁垒的寓意。团队一起合作，独特为他们的利用和零碎负责。
局部度量参考：
- 开发利用所破费的最高工夫（开发速率）
- 失败部署的百分比（部署成功率）
- 客户产生了多少问题（客户接受度）
- 故障复原的均匀工夫（团队解决故障的能力）
- 用户数（用户欢送度）
作者：IDCF 社区冬哥
IDCF 社区共创读书会 首期汇报，每周四晚 8 点， 冬哥有话说 收费直播，关注公众号回复“共读”获取直播地址
- 8 月 19 日，共读《思考，快与慢》
- 8 月 26 日，共读《DevOps 实际指南》
- 9 月 2 日，共读《麻利无敌之 DevOps 时代》