DevOps 实践

凤凰项目：一个IT运维的传奇故事

The Phoenix Project
A Novel About IT, DevOps, and Helping Your Business Win

[美] 基恩·金 (Gene Kim) 凯文·贝尔 (Kevin Behr) 乔治·斯帕福德 (George Spafford) /著

COO = Chief Operation Officer 首席营运官
CIO = Chief Information Officer 首席信息官 / = “Career Is Over” 职业生涯结束了
ITIL = Information Technology Infrastructure Library 信息技术基础架构库
ITSM = Information Technology Service Management 信息技术服务管理
WIP = Work in Process 在制品

经典语录

有些书适合给你的朋友，为了分享阅读的喜悦；有些书适合给你的同事，为了建立理念的共识；有些书适合给你的老板，为了播下伟大的种子。

电影《拯救大兵瑞恩》：这里有一系列的命令：只可对上抱怨，不许对下牢骚。

虚构人物语录

比尔·帕尔默：

• 要想在IT运维管理的岗位上做得长久，一定得有足够的资历，这样才能把事情干好。但是一定要低调，不能卷入政治斗争，以免惹祸上身。副总裁们整天做的就是互发PPT。
• 俗话说得好，如果你的同事主动告诉你他们要离职，那多半是自愿的。但如果是其他人告诉你的，那他们一定是被迫的。
• 海军陆战队，保持军营干净整洁不只是为了美观，更是为了安全。
• 靠道听途说可没法破案，当然也没法解决服务中断故障。
• 知道真相总好过一无所知。
• 再也没有比阻止人们去做他们理应做的事更能毁掉大家的热情和支持了。我不认为我们还能有第二次机会让事情走上正轨。
• 80/20法则在这里似乎同样适用：80%的风险是由20%的变更造成的。
• 流程是用来保护人的。
• 埃瑞克把半成品称为“沉默的杀手”，车间控制半成品的能力不足，是造成长期性延误和质量问题的根源之一。
• 搞死你的不是前期投入，而是后台的运行和维护。
• 告知真相是一种爱的表现。隐瞒真相是一种恨的表现。甚至更糟，是一种冷漠的表现。
• 开发和QA的环境与生产环境不匹配，绝对不应该发生这样的事。

埃瑞克：

• 只有掌握了战术，才能实现战略目标。
• 半成品是个隐形杀手。因此，管理任何一家工厂最关键的机制之一，就是工作任务和原材料的发布。没有这个机制，就无法控制半成品。
• 不应该根据第一个工作站的效率来安排工作，而是根据瓶颈资源所能完成工作的速度来安排工作。
• 创建约束理论的艾利·高德拉特告诉我们，在瓶颈之外的任何地方做出的改进都是假象。（所有在非约束点所做的改进都是假象）
• 作为IT运维部的副总裁，你的工作是确保形成一条迅速、可预测、持续不断的计划内工作流，从而向业务部门交付工作价值，同时尽可能降低计划外工作的影响和破坏，那样你才能提供稳定的、可预期的、安全的IT服务。
• 反复实践是精通工作的先决条件。
• 不仅仅是要减少半成品。相比于向系统中投入更多的工作，将无用的工作剔出系统更为重要。
• 重要的是结果，而非过程、管理，或者你完成了哪些工作。
• 每个工作中心都由四种东西组成：机器、人员、方法，以及测评。
• 研究表明，每天训练5分钟比每周开展一次为期3小时的训练更有效。
• 一个给定资源的等待时间，是那个资源忙碌时间的百分比除以空闲时间的百分比。因此，如果一个资源使用了50%，等待时间就是50/50，或者说1个单位。
• （信息安全）可以不对IT系统做过多无用功就保护公司，这才是你的胜利。如果你能把那些无用功剔出IT系统，你的胜利就更进一步。
• 把整个环境创建流程自动化。
• 要记住，你身边有很多经验丰富的人，他们也踏上过同样的旅程，所以，你可别因为不去找人帮忙，而变成一个失败的傻瓜啊。
• 一时的救世主固然好，但普世的圣经则更有用。

史蒂夫：

• 一个伟大的团队并不代表他们拥有最聪明的人。使团队变得伟大的因素，是每个人都互相信任。当那种神奇的动力出现，就会让整个团队充满力量。（凝聚力）
• 兰西奥尼教导我们，展现自己脆弱的一面有助于建立起信任的基础。
• IT不只是一个部门。相反，它就像电力一样无处不在。IT是一种技能，就像能读会算一样。
• 每一个称职的COO都会是从IT部门出来的。任何尚未精通IT系统就负责管理公司运行的COO，都只会是金玉其外的傀儡，需要依靠别人来开展工作。

玛姬·李：

• 在竞争的时代，游戏规则就是“快速上市，快速淘汰”。我们需要短而快的周期，不断整合来自市场的反馈。

现实人物语录

卡伦·马丁和麦克·奥斯特林《Value Stream Mapping》：
价值流：一个组织基于客户的需求所执行的一系列有序的交付活动，或者是为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值。

爱德华·戴明博士：没人会强迫你学习……学习也并非生存必需。（自驱的学习才有用）
克里斯托弗·利特尔：DevOps不仅是自动化，就像天文学不只是望远镜一样。
通用电气公司 首席执行官 伊梅尔特：没有将软件作为核心业务的每一个行业或公司都会受到影响。
微软 技术院士 杰弗里·斯诺弗：在过去的经济时代，企业通过移动原子创造价值。而现在，他们必须通过数字创造价值。
克里斯托弗·利特尔：每个公司都是科技公司，无论他们认为自己处在哪个行业。银行也只是拥有银行执照的IT公司而已。
高德拉特博士《目标之外》：在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象。
休哈特：循环（即PDCA环）——计划（Plan）、实施（Do）、检查（Check）、改进（Act）。
麦克·奥泽恩：比日常工作更重要的，是对日常工作的持续改进。

帕特里克·兰西奥尼《团队发展的五大障碍》：
1.缺乏信任；2.惧怕冲突；3.欠缺投入（投入激情）；4.逃避责任；5.无视结果。

项目管理

变更：对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作，并且这样的操作可能对相关服务产生影响。

技术债务：沃德·坎宁安首次提出。类似于金融债务。我们当前所做出的决定会导致一些问题，而这些问题随着时间的推移会越来越难解决，未来可采取的措施也越来越少。即使我们审慎地承担技术债务，也依然会产生利息。

分钟级别的部署前置时间的方法：
向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试，然后再将它部署到生产环境中。这样，我们就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复可能出现的问题。

预防措施有个问题，就是你很少能知道自己究竟避开了哪些灾难。
要想在现代技术上取得成功，必然需要多方向和多专业领域的协作。
想要在团队中达成相互信任，你需要展现出自己脆弱的一面。
更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。
产品负责人不应该只关注具有创新性的产品和功能，还需重视维护工作和移除技术债务等优先级。
任何一个领域或学科想要取得进步和成熟，就需要认真反思它的起源，在反思中寻求不同的观点，并把这些不同观点的来龙去脉思考清楚，这对预见未来发展是非常有帮助的。

IT运维、信息安全和开发等不同职能部门之间的良好合作是成功的关键。
一个IT做得失败的公司，整个公司也都是失败的。
IT公司的任务和价值：

• 对变化莫测的市场做出反应；
• 为客户提供稳定、可靠和安全的服务。

界定问题的性质：
1.经常发生的问题——流程制度
2.偶然发生的问题——规则方法
3.首次发生的“经常问题”——重点决策

提高效率三要素：稳定环境，减少切换成本；可视化目标，掌握全局；紧紧盯住约束点，抓住关键。

四类工作：业务项目，内部项目，变更，计划外工作（破坏性最强）。

五个聚焦步骤：
1.确认约束点。找不到真正的瓶颈，做什么都是多余。
2.利用约束点。不能让约束点闲着，让它一直运转，而不是需要他才运转。
3.迁就约束点。以瓶颈的产出速度作为整个项目的产出速度。使布伦特解决完一个关键后马上解决下一个关键问题，只做关键工作，疏通瓶颈，避免半成品过剩。
4.消灭约束点。可以通过增员，引进新技术，跳过瓶颈等方式提高瓶颈产出速度，降低瓶颈对项目进程的约束。
5.发现新的约束点。主要矛盾被解决后，次要矛盾会上升为主要矛盾。在约束点被消灭后，找到新的约束点，聚焦它，将进一步提高产能。工作流将越来越流畅高效。

DevOps

DevOps = Development & Operations 开发和运维
infrastructure as code 基础设施即代码
CI = Continuous Integration 持续集成
CD = Continuous Deployment / Continuus Delivery 持续部署/持续交付

“每日10次部署”
DevOps的准则：总有更好的方法
DevOps的原则和模式就是通过整合企业文化、企业架构和技术实践，让下降式螺旋变成上升式螺旋。
DevOps是把精益原则应用到技术价值流中的结果。
DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。
精益的两个主要原则：

• 坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一
• 小批量任务的交付是缩短前置时间的一个关键因素

在DevOps中，技术价值流：把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程。
流程的输入是既定的业务目标、概念、创意和假设，始于研发部门接受工作，并将它添加到待完成工作列表中。
技术价值流的核心是建立高度信任的文化。

三步工作法：
第一工作法，建立工作流并以可视化方式呈现
第二工作法，根除计划外工作的最大源头
第三工作法，不断给系统增加压力，使其习惯并强化。

三步工作法的原则：

• 流动原则：它加速了从开发、运维到交付给客户的流程。
  使工作可见；限制在制品数；减小批量大小；减少交接次数；持续识别和改善约束点；消除价值流中的困境和浪费。
• 反馈原则：它使我们能建立更加安全可靠的工作体系。
  在复杂系统中安全地工作；及时发现问题；群策群力，战胜问题获取新知；在源头保障质量；为下游工作中心而优化。
• 持续学习与实验原则：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。
  建立学习型组织和安全文化；将日常工作的改进制度化；把局部发现转化为全局优化；在日常工作中注入弹性模式；领导层强化学习文化。

更快、更廉价、更低风险的软件交付趋势正加速发展：

	1970~1989 年	1990~1999 年	2000 年~至今
时代	主机	客户端/服务器	商品化和云计算
标志性技术	COBOL、运行在MVS上的DB2等	C++、Oracle、Solaris等	Java、MySQL、RedHat、Ruby on Rails、PHP等
交付周期	1~5年	3~12个月	2~12个星期
成本	100万~1亿美元	10万~1000万美元	1万~100万美元
风险级别	整个公司	产品线或部门	产品特性
失败成本	破产、出售公司、大量裁员	业务亏损、CIO革职	可忽略不计

罗恩·韦斯特拉姆的组织类型学模型：

病态型	官僚型	生机型
隐瞒信息	忽略信息	积极探索信息
消灭信使	不重视信使	训练信使
逃避责任	各自担责	共担责任
阻碍团队的互动	容忍团队的互动	鼓励团队间结盟
隐瞒事故	组织是公道和宽容的	调查事故根因
压制新想法	认为新想法会造成麻烦	接纳新想法

思想感悟

• 浴火重生的叫凤凰，浴火成灰的叫火鸡。
• 获得别人好感，拉进别人距离的好办法就是很自然的说出这个人的一些事儿。
• 在约束理论中曾经提到过，所有人都在忙碌是一件很可怕的事情，这不是高效的表现。所有在非瓶颈处的更高效率都是无用功，甚至可能有副作用。
• 工作的动力大部分是成就感，而不是一直被某些人或者事情追着跑。需要时间静下心来思考。

IT技术，应用层日新月异，要保持学习；底层变化不大，要夯实基础。基础不牢，地动山摇。

独角兽项目：数字化转型时代的开发传奇

The Unicorn Project
A Novel about Developers, Digital Disruption, and Thriving in the Age of Data

[美] 吉恩·金 著

ITIL = Information Technology Infrastructure Library 信息技术基础架构库
TEP-LARB = Technology Evaluation Process - Lead Architecture Review Board 技术评估流程表-首席架构审查委员会
STEM：Science 科学，Technology 技术，Engineering 工程，Mathematics 数学。
FAANG：美国市场上五大最受欢迎和表现最佳的科技股的首字母缩写，即社交网络巨头Facebook（NASDAQ:FB）、苹果（NASDAQ:AAPL）、在线零售巨头亚马逊（NASDAQ:AMZN）、流媒体视频服务巨头奈飞（Netflix，NASDAQ:NFLX）、谷歌母公司Alphabet（NASDAQ:GOOG，NASDAQ:GOOGL）。
HPPO效应：Highest Paid Person’s Opinion，最高收入者意见。
big wad of crap 一大团废物

名词术语

• 竞态条件 race condition：设备或系统出现不恰当的执行时序，而得到不正确的结果。从多进程间通信的角度来讲，是指两个或多个进程对共享的数据进行读或写的操作时，最终的结果取决于这些进程的执行顺序。
• “海森堡 bug”：观察行为改变了现实本身性质的量子物理现象。
• 亚马逊的“两个比萨团队”原则：用两张比萨可以喂饱的团队就能创建出功能特性。
• 塔克曼的团队阶段模型：形成期、动荡期、规范期和高效期。
• 混沌工程：在生产环境中对软件系统进行实验的学科，目的是建立对系统承受动荡和意外情况能力的信心。
• 惊群问题：同时进行的客户端重试最终导致服务器挂掉。在计算机科学中是指，如果许多进程在等待一个事件，事件发生后这些进程被唤醒，但只有一个进程能获得CPU执行权，其他进程又得被阻塞，从而造成严重的系统上下文切换代价。
• 现金牛 cash cow：拥有高市场占有率及低预期增长的业务。
• 霍尔原则 Hoare principle：写代码有两种方法：写得非常简单，显而易见没有bug；写得非常复杂，没有显而易见的bug。
• 沃德利映射 Wardley Map：从客户的需求入手，逐步绘出满足这些需求的各个功能和系统，以及这些功能和系统的演进，以呈现出组织内部存在的价值链。
• 美国心理学家库伯勒−罗斯（Kübler-Ross）将身患绝症的患者从获知病情到临终时期的心理反应和行为改变归纳为5个典型阶段：否认期、愤怒期、讨价还价期、抑郁期和接受期。

经典语录

• 孤立地理解系统的任何部分都是很困难的。
• 信任的缺乏和太多嘈杂的信息让事情进展得越来越慢。
• 能够测试并将代码部署到生产环境更有助于提高产能和客户满意度，而且有助于程序员提升对代码质量的责任感，同时使其工作变得更令人愉悦、更有价值。
• 优秀的 QA 需要一种反常的、有时甚至是残酷的直觉，知道什么会导致软件爆炸、崩溃或无休止地挂起。
• 每个人都能及时将自己的变更合并到“主分支”，比如每天一次。这样，合并的变更就不会太大。就像在制造业里，小批量生产可以创造平稳的工作流程，没有相互冲突的中断或灾难。
• 我们甚至不再需要警卫了。我们太喜欢做囚徒了，认为那些栅栏是为了保护我们的安全而设。
• 永远背负这么多未兑现的承诺，真的是一种认知和精神负担。
• 工程师应该编写代码，而不是填写表单。
• 没有优秀设计师的应用常常被戏称为“企业级”的。原文为 enterprisey，用于形容为大型商业公司开发的软件，常用作贬义指过度设计、不合目的。
• 要想表达清晰，就必须思维清晰。要想思维清晰，就必须记录清晰。
• 伟大可以被扼杀，但也可以被修复。
• 当每个人都清楚目标是什么时，团队就会自我组织起来，以最好地实现这些目标。
• 领导者必须以身作则，示范他们期望的行为模式。
• 成年学习者经常掩盖他们正在试图学习一项新技能的事实，无论是学习一门新语言还是学游泳，甚至是上高尔夫球课。这通常是因为他们尴尬或害怕被人看到自己做不擅长的事情。
• 吸引优秀人才有一个意想不到的方式：通过公司令人惊叹的全新开源项目。
• 技术需要嵌入到业务中，而不是与业务无关，或者仅仅是“与业务保持一致”。
• 恐惧文化所造成的破坏性影响。在这种文化中，错误的行为通常会受到惩罚，替罪羊会被解雇。惩罚失败和“枪杀信使”只会让人们掩盖自己的错误。最终，所有创新的欲望都会被彻底磨灭。
• 当人们不能持续构建他们的应用时，灾难通常就在眼前。
• 有比代码更重要的东西是使开发人员能够高效工作的系统。
• 付出大于回报总是好事，因为你永远不知道将来谁可能会帮助你。人脉很重要。
• 当工程师抽象地思考“客户”而不是真实的人时，很少会得到正确的结果。
• 法律谚语：现实占有，九胜一败。指占有人在诉讼中处于有利地位。

一个笑话：一个 QA 工程师走进一家酒吧。点了1杯啤酒。点了0杯啤酒。点了999 999 999杯啤酒。点了1只蜥蜴。点了-1杯啤酒。点了1个 sfdeljknesv。

现实人物语录

孙振鹏：Patrick Debois: DevOps beyond Dev and Ops。意思是DevOps应超越开发和运维，服务于整个企业或组织，更快、更可靠、更安全地交付对用户更优的价值，助力数字化转型，让业务蓬勃发展，让企业基业长青。
张乐：别只惦记着眼前的几捆“白菜”，技术创新实践的星辰大海、未来的无限可能性更令人心潮澎湃！
PowerShell的发明者杰弗里·斯诺弗：Bash 是一种你会携带一生但不会致死的疾病。

虚拟人物语录

史蒂夫：

• 安全永远排在第一位。
• 技术债务就是指造成困难、重复劳动，并降低软件工程师敏捷性的东西。
• 只要一个团队充满激情、致力于完成一项使命，并且拥有对的技能，那么与他们作对就是愚蠢的，因为他们会竭尽全力让一切成为现实。
• 过去几百年甚至未来上千年都会是这样：员工敬业度和客户满意度是唯一重要的事情。如果我们做到了这一点，并有效地管理现金，其他所有财务目标都会自动达成。
• 我们的未来取决于创新。创新不是来自流程，而是来自人。
• 我们的业务是建立在客户信任的基础上的。我们已经向客户承诺，保护他们的隐私和数据。

玛克辛·钱伯斯：

• 开发人员需要一个系统，以便快速并持续地获得关于其工作质量的反馈。如果你没能很快地发现问题，那么最终会在几个月后发现。但到那时，问题已经消失在其他开发人员所做的大量修改中了，而因果关系也会消失得无影无踪。任何项目都无法这样进行下去。
• Oh, the Places You’ll Go。
• 美好的一天是当她在解决一个重要的业务问题时，时间过得飞快，因为她是那么专注，那么热爱这份工作。她处于心流状态，以至于根本感觉不到是在工作。
• 糟糕的一天就是她沮丧得想撞显示器，在网上搜索一些她根本不想学但为了解决手边的问题必须要学的东西。
• 无论你们使用什么语言，最重要的是不断运行你们的程序。经常运行程序的真正好处之一是你们可以看到它在运行。这很有趣，这就是编程的意义。
• 状态突变和循环是非常危险的，而且很难纠正。
• 作为项目的所有者，她把确保每位贡献者都能拥有很高的生产力视为自己的首要职责。
• 在几乎所有其他领域，特别是当你有客户的时候，变化是常态。健康的软件系统是可以按照所需的速度来进行变更的，人们可以很容易地做出贡献，而不需要跨越重重关卡。这就是让一个项目有趣并值得贡献的秘诀，你会经常看到最有活力的社区就是这样的。
• 她能够以专注、流动和快乐的状态来创造东西。她的工作很快得到了反馈。人们可以做自己想做的事情，而不需要依赖很多人。这就是伟大的架构所能实现的。
• 之所以生产部署是任何技术组织中最复杂的活动之一，是因为这需要在组织中进行如此多部门之间的协调。
• 如果你无法获取关于如何使用程序的反馈，又怎能创造出有价值的东西呢？
• 拥有一个优秀的构建过程是得到良好的代码部署和发布过程的关键。
• 每个决策都是一种承诺，要支持好几年甚至几十年——这远远超出了某个团队的能力范围。
• 找到同类，这就是有效的人际网络的意义所在——你可以召集一群积极的人来解决一个大问题，即使这个团队看起来一点也不像官方组织。
• 之所以痛苦，是因为合并的规模太大了。为了减少痛苦，他们需要更频繁地进行合并，这样合并的规模就会变小，产生的冲突也会更少。
• 环顾四周，她发现公司里最好的工程师都在努力提高其他人的工作效率。“就应该这样。”
• 如果有什么时候需要勇气和不懈的乐观，那就是现在。
• 他们能够取得现在成就的唯一途径，就是创造一种让人们感到安全的文化，从而去实验、学习和犯错，让人们有时间进行探索、创新和学习。
• 对于如此关键的任务，我们不应该依赖外部服务。当它们不工作或断开我们的调用时，我们需要优雅地进行处理。
• 小不一定能胜大。但是，快一定能胜慢。行动迅速的大块头几乎每次都会赢。

库尔特·雷茨尼克：

• 一旦我们可以持续构建，就能进行自动化测试。有了自动化测试，我们就可以更快、更有信心地进行变更，而不必依赖数百小时的手动测试。我相信，这是让我们更安全、更快、更幸福地交付更佳价值的关键第一步。我们需要在构建或测试过程中发现问题，而不是在部署期间或生产环境上。
• 预防需要诚实，诚实需要无所畏惧。就像诺曼·克尔斯在敏捷最高境界中指出的那样：“不管发现了什么，我们都理解并相信每个人都已经全力以赴，只是受限于他们当时所知道的、他们的技能和能力、可用的资源和手头的情况。”
• 在危机中，我们永远不知道真正在发生什么，而且我们需要为未来做准备。在未来，我们对世界的理解也会同样不完美。

埃瑞克：

• 交织（complect）就是把简单的东西变成复杂的东西。在紧耦合和交织的系统中，几乎不可能改变任何东西。
• 代码部署前置时间、代码部署频率和问题解决时间是软件交付、运营效能和组织绩效的预测指标，它们与职业倦怠和员工敬业度等很多因素相关。
• 简单性很重要，因为它促成了局部性。代码中的局部性使系统保持松耦合，使我们能够更快地交付功能特性。团队可以快速而独立地开发、测试，并把价值传递给客户。
• 底层的架构至关重要，关乎开发人员在日常工作中使用的系统是否高效。
• 创新和学习发生在边缘，而不是核心。必须在第一线解决问题，因为那里每天的工作是由世界上最频繁面对这些问题的前沿专家来完成的。
• 心理安全是卓越团队最重要的因素之一。团队有信心，不会因为有人发言而尴尬，受到否决或惩罚。出现错误时，我们会问“是什么原因导致的”，而不是“是谁导致的”。我们承诺尽一切努力让明天比今天更好。
• 未来需要创建一个动态的学习型组织。在这个组织中，实验和学习是每个人日常工作的一部分。
• 与初创公司相比，现代企业拥有更多资源和专业知识。我们需要的是专注和紧迫感，以及管理价值创造过程的现代方法。
• 沃德·坎宁安：技术债务是你下次想要做出变更时感觉到的。
• 比尔盖茨：如果开发人员必须在实现功能特性和提高安全性之间做出选择，他们必须选择后者，因为这关系到公司的存亡。
• 斯蒂芬·斯皮尔博士：无知是所有问题的根源，唯一能克服它的是学习。
• 爱德华兹·戴明：一个糟糕的制度每次都会击败一个好人。
• 约翰·奥斯帕：每个事故都是一次学习的机会，一次未经同意的计划外投资。
• 乔布斯：安全是一切工作的前提。
• 奥尼尔：每个人都必须对自己的安全和队友的安全负责。如果你看到什么东西可能会伤害到别人，就必须尽快修复。
• 克雷·克里斯坦森：我们自己管理“不够好”的东西，将“非常好”的东西外包出去。

柯尔斯顿：

• 公司的最高层不仅要做正确的事情，而且要把正确的事情做对。按时发布代码就是其中一部分。

戴夫

• 每个开发人员都知道，以后需要在编写功能特性的同时编写自动化测试，而不是在之后。（测试驱动）

黛布拉：

• 事实永远比想法有价值得多。

开发实践

绞杀者模式一般用于传统旧系统（大部分是单体）向微服务架构的改造和迁移的过程中。在旧系统中创建一个绞杀者外层（类似扔了一粒无花果种子在旧系统中），然后随着新功能的引入（无花果发芽生长），最终旧系统慢慢被替换成完整的新系统（宿主死亡）。

编程方法论：

1. 命令式编程
   关注程序的执行流程和状态，程序员定义执行的步骤，而不是定义要达到的目标。
   程序由一系列语句组成，其中包括条件语句、循环语句、赋值语句等。语句由计算机解释器或编译器按顺序执行，程序状态在执行过程中不断变化。程序员需要负责跟踪和维护程序状态，以确保程序按照预期执行。
   适用于实现算法、操作系统、驱动程序、图形用户界面等领域。
   常见的编程语言包括C、Java、Python、C++等。
2. 函数式编程
   强调使用函数和避免变量状态和可变数据。
   主要是基于数学中的λ演算发展而来，它的基础是数学和逻辑学。
   广泛应用于处理函数对象和集合、函数式语言、科学计算、并行和分布式计算、Web应用程序等领域。
   常见的函数式语言包括Lisp、Haskell、Erlang、Scala、Clojure等。
   纯函数：其输出完全依赖于输入，没有副作用、突变或全局状态访问。
   不可变性，使世界变得更可预测、更安全。
3. 面向对象编程
   以对象为中心，通过封装、继承、多态等机制来组织程序结构和实现功能。
   可以提高程序的重用性、可扩展性、可维护性和可读性。
   广泛应用于各个领域，包括软件开发、游戏开发、物联网、人工智能、图形用户界面等。
   常见的面向对象编程语言包括Java、Python、C++、C#、Ruby等。

DevOps

三个视野（Three Horizons），杰弗里·摩尔博士推广。
客户采纳是一个高斯分布曲线，可以划分为创新者、早期采纳者、早期大多数、晚期大多数和落后者。

波士顿矩阵：
公司若要取得成功，必须拥有“市场增长率”和“相对市场份额”各不相同的产品组合。用这两个维度画一个“二维四象限矩阵图”，并给这个矩阵中的四象限，起了几个形象的名字：现金牛，明星，问题，和瘦狗。

1. 现金牛业务
   现金牛业务被戏称为“印钞机”，通常有很高的相对市场份额，也因此市场增长率显得低。
2. 明星业务
   明星业务通常是很有前景的新兴业务，在一个快速增长的市场中，占据了相对高的市场份额。一旦明星业务成为现金牛，公司就进入下一个爆发期。
3. 问题业务
   问题业务是一些相对市场份额还不高，但市场增长率提高很快的业务。它们最终会成为明星业务，甚至现金牛业务，还是会死掉，是不确定的问题。
4. 瘦狗业务
   瘦狗业务是相对市场份额很低，也看不到什么增长机会的，食之无味弃之可惜的业务。

波士顿矩阵的四种战略建议：

1. 发展战略
   就是不惜用“现金牛业务”的收益，大举投入到“问题业务”中，以提高相对市场份额，尽快成为“明星业务”的战略。
2. 保持战略
   就是不轻易投资新方向，好好养牛，维持市场份额，让“现金牛业务”产生更多的收益。
3. 收割战略
   对强大的替代产品已经出现的“现金牛业务”，比如柯达的胶卷相机，和发展前景不佳的“问题业务”和“瘦狗业务”，可以考虑尽可能快速收割短期利益，然后准备放弃。
4. 放弃战略
   对于无利可图的“瘦狗业务”，果断清理、撤销、出售，把资源用在其他有前景的业务上。

核心（Core）与非核心（Context）的概念，也就是四个区域的内涵。
核心是组织的核心能力，是客户愿意付钱换取的能力，也是使投资者奖励的能力。
非核心是其余的一切，包括员工餐厅、办公楼之间的摆渡车，以及公司运营必须要做的成千上万件事。它们通常很关键，比如人力资源、薪酬系统和电子邮件。但是我们的客户不会因为我们为员工提供出色的薪酬服务而付钱给我们。

五大理念：
第一理念：局部性和简单性
第二理念：专注、流动和快乐
第三理念：改进日常工作
第四理念：心理安全
第五理念：以客户为中心

思想感悟

• 在占据了我们有限生命的大量时间的工作中，我们对创造价值的追求是共通的。
• 人们总是说“规矩是死的，人是活的”，而又总是制造出死的规矩来约束活的人。
• 公司盈利的极端：
  一个极端是，通过削减成本，把运营中的每一点利润榨取干净，想到了丰田的精益生产；
  另一个极端是，构建多维度业务，做大现金牛、培育明星、挖掘问题业务、抛弃瘦狗业务。

快速反馈，持续交付，敏捷迭代
《独角兽项目》比起《凤凰项目》紧急上线时的惊心动魄，更多的是项目的解耦，架构的重构，团队成员的团结协作。
数据转型？：关系型的SQL，到NoSQL，到大数据

独角兽项目：定制化推荐和促销功能。
独角鲸：新数据库和 API 网关平台。
独角猫 ci-unikitty：持续集成和部署平台。
美洲豹：数据计算平台。

逆戟鲸：分析和数据科学团队

DevOps实战笔记

极客时间 专栏

[中] 石雪峰（京东商城工具效率专家）

DevOps 状态报告，核心是看趋势、看模型、看实践。

《持续交付》围绕着软件交付的原则，给出了一系列的思想、方法和实践，核心在于：
以一种可持续的方式，安全快速地把你的变更（特性、配置、缺陷、试验），交付到生产环境上，让用户使用。

软件交付的 8 大原则：

• 为软件交付创建一个可重复且可靠的过程
• 将几乎所有事情自动化
• 将一切纳入版本控制
• 频繁地做痛苦的事情
• 内建质量
• DONE 意味着已发布
• 交付过程是每个成员的责任
• 持续改进

DevOps 产品的特点：技术背景要求高，面向的用户是开发人员，专业工具繁多。

DevOps 产品经理的修养：

• 自我颠覆
  管理预期。如果产品使用场景有限，又没有很好的增长性，及时叫停反而是一种好的选择。
• 化繁为简
  始终记得，不要让你的产品只有专家才会使用。将复杂的问题简单化，是产品经理不论何时都要思考的问题。
• 退后一步
  不要把关注点只聚焦在问题表面，而是要尽量站在旁边，以第三方的视角来全面审视问题。
  能够在用户思维和实现思维之间自由切换，是产品经理走向成熟的标志。
  构建块 building block，是指一整块的代码片段，而不是一条条独立的指令。

DevOps文化：
协作、分享共担、无指责文化、在错误中学习。
通过对外开放透明，建立信任，促进协作；
打造心理安全的氛围，鼓励创新；
开源为先的共享精神。

对错误的态度和重视程度，决定了成长的高度。
假如说我要去一家公司面试，面试官问我有没有问题，那我非常关心的一定是他们公司对错误的态度，以及具体的实际行动。

美国硅谷的IT精英公司： FAANG = Facebook, Apple, Amazon, Netflix, Google

OKR = Objectives and Key Results 目标与关键成果法
是在硅谷互联网公司很流行的绩效制定方法。
O 代表目标，是我们要做什么。
KR 代表关键结果，用于验证我们是否已经达到了目标。

经典语录

• 每一家公司都将成为软件公司。
• 软件交付的效率和质量成了当今企业的核心价值和核心竞争力。
• 机制就是人们愿意做，而且做了有好处的事情。
• 新思想和新技术的发展，总是同标准化的模型和框架相伴相生的。
• 任何技术的成熟，都是以模型和框架的稳定为标志的。
• 啥都懂点儿，但是啥都不精通，本身就是IT从业者在职业发展道路上的大忌。
• 没有天然完美的解决方案，只有持续优化的解决方案。
• 持续改进和对人的尊重，才是一切改进方法的终极坐标。
• 不仅要低头看路，还要抬头看天。（仰望星空与脚踏实地）
• 任何技术的走向成熟，都是以模型和框架的稳定为标志的。
• 建立自己的知识体系，持续进行输出式学习。
• 完成比完美更重要，很多事情可以先干再说。
• 让计划帮你守住底线，让行动为成功添砖加瓦。
• 在企业中，要么提升自己的执行力，要么提升自己的创新力，要么让自己能够快速地整合资源，只有这样，你才能具备成功的资本。
• 每一行代码都是你的名片，每一个产品都是你的代言人。
• 但凡能打硬仗的同事，在后来都是非常靠谱且独当一面的，这与年龄无关，哪怕是应届生，也同样如此。
• Use what you build to build what you use.（使用你开发的工具来开发你的工具）
• 国家智库某领导：工业革命消灭了绝大多数的手工业群体，却催生了程序员这个现存最大的手工业群体。（手工作坊式的软件开发）
• 质量管理大师戴明博士：Don’t just do the same things better – find better things to do.
• 管理学大师爱德华·戴明博士：If you can’t measure it, you can’t manage it.
• 亚马逊CEO贝佐斯：要把战略建立在不变的事物上。
• 美国著名女演员莉莉·汤姆林 Lily Tomlin：The road to success is always under construction.（通往成功的道路，永远在建设之中）

基础理论

在传统模式下，开发团队，度量效率的途径是，看开发完成了多少需求。
运维团队，考核指标是，系统的稳定性、可用性和安全性。

定义

DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 C（Collaboration 协作）A（Automation 自动化）L（Lean 精益）M（Measurement 度量）S（Sharing 共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。

价值

DevOps 的 4 个结果指标：

• 部署频率：指应用和服务向生产环境部署代码的频率。
• 变更前置时间：指代码从提交到成功运行在生产环境的时长。
• 服务恢复时间：指线上应用和服务出现故障到恢复运行的时长。
• 变更失败率：指应用和服务在生产环境部署失败或者部署后导致服务降级的比例。

软件交付的两个最重要的方面：交付效率和交付质量。
DevOps的核心价值：高效率和高质量。
提升效率最直接的手段：工具和自动化。
DevOps 的行为准则：让一切都自动化。

实施

需要将规则内建于工具之中，并通过工具来指导实践。
DevOps 的 3 个支柱 = 人 People + 流程 Process + 平台 Platform

• 人 + 流程 = 文化
  《一代宗师》：真正的高手，比拼的不是武功，而是思想。
  DevOps 的文化就是指导 DevOps 落地发展的思想。责任共担，质量导向。

• 流程 + 平台 = 工具
  平台的最大意义，就是承载企业内部的标准化流程。
  平台上固化的每一种流程，都是可以用来解决实际问题的工具。
  平台因素：用户量、认可度、老板加持等。
  平台的显著特征：

  • 吸附效应：平台会不断地吸收中小型的工具，逐渐成为一个能力集合体。
  • 规模效应：平台的成本不会随着使用方的扩展而线性增加，能够实现规模化。
  • 积木效应：平台具备基础通用共享能力，能够快速搭建新的业务实现。

工具是自动化的载体，自动化可以说是 DevOps 的灵魂。
平台就是搭台子，工具来唱戏。

• 平台 + 人 = 培训赋能

衡量

《跨越鸿沟》，技术采纳生命周期定律：一项新技术从诞生到普及要经历的 5 个阶段，分别对应一类特殊人群，即创新者、早期使用者、早期大众、晚期大众和落后者。技术的发展不是线性的，需要经历一段蛰伏期，才能最终跨越鸿沟为大众所接受，成为业界主流。

“道法术器”
数字化转型的核心在于优化软件交付效率。
模型和框架是能力和实践的集合。

ITIL V4 指导原则：关注价值、关注现状、交互式流程和反馈、协作和可视化、自动化和持续优化、极简原则、关注实践。

DevOps 工程师主要职责

工具平台开发，流程实践落地，技术预研试点。
理念和实践的宣导，内部员工的培训，持续探索，发现流程的潜在优化点等。

能力模型分为两个方面：

• 通用能力（软实力）：沟通能力（向上沟通、向下沟通、横向沟通），学习能力，同理心
• 专业能力（硬实力）：技术能力（代码能力、自动化能力、IT基础能力、容器云能力、业务和流程能力）

当硬实力到达天花板之后，软实力的差异将决定一个人未来的高度。
培养团队以用户为中心的思想。用户，不是外部用户，而是在交付流程中存在交付关系的上下游部门。
真正的学习者都是在没有条件来创造条件的过程中学习的。先干再说。
勤练习，多总结。就像 DevOps 一样，持续改进和持续反馈，培养自己的自信心。

企业需要的不仅仅是一个工具，而是工具所关联的一整套解决方案，其中最重要的就是业务流程。

落地实践

价值流

VSM = Value Stream Mapping 价值流图
价值是带给企业生存发展的核心资源，比如生产力、盈利能力、市场份额、用户满意度等。
VSM 是一场团队协作的试炼。
关键要素：

• 前置时间 LT=Lead Time
• 增值活动时间和不增值活动时间 VAT/NVAT=Value Added Time/Non-Value Added Time
• 完成度和准确度 %C/A=% Complete/Accurate。

开展 VSM 的 2 种方式：召开一次企业内部价值流程梳理的工作坊或者会议，内部人员走访。
VSM 的 5 大价值：看见全貌、识别问题、促进沟通、驱动度量、价值展现。

通过流程和平台的结合，来驱动流程的自动化流转，这才是 DevOps 的正确姿势。
DevOps 追求的是价值流动效率最大化。

转型

两种轨迹：一种是自底向上，一种是自顶向下。
寻求管理层的认可和支持都是一个必选项。

通用路径：

• 第 1 步：寻找合适的试点项目。贴近核心业务，倾向敏捷业务，改进意愿优先。
• 第 2 步：寻找团队痛点
• 第 3 步：快速建立初期成功
• 第 4 步：快速展示和持续改进

康威定律：一个团队交付的系统结构和他们的组织结构是相同的。
持续的增量交付和不断的反馈建议，也是现在保证产品需求有效性的最佳手段。
想要推进 DevOps，敏捷开发实践和需求价值分析都是必不可少的要素。
尽量避免从大型团队开始入手，专注于中型团队。

业务敏捷

交付能力的提升，可以帮助业务以最小的成本进行试错，将新功能快速交付给用户。

产品需求管理的核心思想：开发更少的功能，聚焦用户价值，持续快速验证

需求分析方法：影响地图。
影响地图是通过简单的“Why-Who-How-What”分析方法，实现业务目标和产品功能之间的映射关系。

• Why 代表目标，它可以是一个核心的业务目标，也可以是一个实际的用户需求。
• Who 代表影响对象，通过影响谁来实现这个目标。
• How 代表影响，怎样影响用户以实现我们的目标。
• What 代表需要交付什么样的功能，可以带来期望的影响。

需求优先级安排：
卡诺模型（Kano Model），日本大师授野纪昭博士提出的一套需求分析方法。
核心要做到3点：优先规划期望型和必备型需求，识别无差别型和反向型需求，追求兴奋型需求。
卡诺模型将产品需求划分为五种类型：

• 兴奋型：指超乎用户想象的需求，是可遇不可求的功能。
• 期望型：用户的满意度会随着这类需求数量的增多而线性增长，做得越多，效果越好，但难以有质的突破。
• 必备型：产品必须要有的功能，如果没有的话，会带来非常大的影响。
• 无差别型：做了跟没做一样，典型的无用功。
• 反向型：无中生有类需求，实际上根本不具备使用条件，或者用户压根不这么想。

用户故事则是以用户的价值为核心，圈定一种角色，表明通过什么样的活动，最终达到什么样的价值。
检验用户故事拆分粒度是否合适，可以遵循 INVEST 原则：

• Independent 独立的：减少用户故事之间的依赖，可以让用户故事更加灵活地验证和交付，而避免大批量交付对于业务敏捷性而言至关重要。
• Negotiable 可协商的：用户故事不应该是滴水不漏、行政命令式的，而是要抛出一个场景描述，并在需求沟通阶段不断细化完成。
• Valuable 有价值的：用户故事是以用户价值为核心的，每个故事都是在对用户交付价值，要站在用户的视角思考问题，避免“我不要你觉得，我要我觉得”。
• Estimatable 可评估的：用户故事应该可以粗略评估工作量，无论是故事点数还是时间，都可以。如果是一个预研性质的故事，则需要进一步深挖可行性，避免不知道为什么做而做。
• Small 小的：用户故事应该是最小的交付颗粒度，所以按照敏捷开发方式，无论迭代还是看板，都需要在一个交付周期内完成。
• Testable 可测试的：验收条件，如果没有办法证明需求已经完成，也就没有办法进行验收和交付。

需求价值的度量：

• 客观指标：客观数据能够表明的指标。如加入购物车率、完成订单率等。
• 主观指标：无法直接度量，只能通过侧面数据关联得出。如用户体验、用户满意度、用户推荐率等。

Business + DevOps = BizDevOps，核心理念：

• 对齐业务和开发目标、指标
• 把握安全、合规指标
• 及时对齐需求，减少无用开发
• 体现 DevOps 的价值
• 让开发团队开始接触业务，不单单是执行，调动积极性

Security + DevOps = DevSecOps

精益看板

敏捷常用的两种框架：Scrum 和看板。
看板，日语词汇，カンバン / Kanban，泛指日常生活中随处可见的广告牌。
精益看板的核心是关注价值流动，加速价值流动。在软件开发中，价值可能新功能、缺陷修复、体验优化。
核心实践是限制在制品数量。
利特尔法则：平均吞吐率 = 在制品数量 / 平均前置时间。
在制品数量是当前团队并行处理的工作事项的数量。
前置时间，衡量 DevOps 产出效果的核心指标，代表从需求交付开发开始到上线发布这段时间的长度。

实践方法步骤：

• 第一步：可视化流程；
• 第二步：定义清晰的规则；
• 第三步：限制在制品数量；
• 第四步：管理工作流程；
• 第五步：建立反馈和持续改进。

看板方法是一种相对温和的渐进式改进方法。
可视化的意义不仅在于让人看得见，还在于让人看得懂。
限制在制品数量有两个关键节点：一个是需求流入节点，一个是需求交付节点。
DevOps 的倡导理念是“You build it，you run it”。要想做到业务敏捷，就得想发就发，做完一个上一个。

在看板方法中，常见的有三种会议：

• 每日站会
  关注两点：待交付的任务，紧急、缺陷、阻塞和长期没有更新的任务。
• 队列填充会议
  目标有两点：一个是对任务的优先级进行排序，一个是展示需求开发的状态。
• 发布规划会议
  以最终交付为目标，实现按节奏部署和按需发布。

配置管理

四个核心理念：版本变更标准化，将一切纳入版本控制，全流程可追溯，单一可信数据源。

变更：对软件做的任何改变。

一套标准化的规则和行为习惯，可以降低协作过程中的沟通成本，一次性把事情做对，这也是标准和规范的重要意义。
标准化是自动化的前提，自动化又是 DevOps 最核心的实践。

“什么什么即代码”，其背后的核心都是版本控制。
如果这个产物可以通过其他产物来重现，那么就可以作为制品管理，而无需纳入版本控制。

把握源头，建立主线。所谓源头，对于软件开发而言，最原始的就是需求，所有的变更都来源于需求。

对于任何一家企业来说，信息过载都是常态，而配置管理的最大价值正是将信息序列化，对信息进行有效的整理、归类、记录和关联。

分支策略

分支策略就是软件协作模式和发布模式的风向标。

• 主干开发，分支发布
  在软件版本发布之前，会基于主干拉出一条以发布为目的的短分支。

• 分支开发，主干发布
  当开发接到一个任务后，会基于主干拉出一条特性开发分支，在特性分支上完成功能开发验证之后，通过 Merge request 或者 Pull request 的方式发起合并请求，在评审通过后合入主干，并在主干完成功能的回归测试。可以加快代码集成频率，特性相对独立清晰。
  如开源社区流行的 GitHub 模式。
  遵守原则：

  • 团队共享一条主干分支；
  • 特性分支的存活周期要尽量短，最好不要超过 3 天；
  • 每天向主干合并一次代码，如果特性分支存在超过 1 天，那么每天都要同步主干代码；
  • 谨慎使用功能开关等技术手段，保持代码干净和历史清晰；
  • 并行分支越少越好，如果可能的话，尽量采用主干发布。

• 主干开发，主干发布
  团队只有一条分支，开发人员的代码改动都直接集成到这条主干分支上，软件的发布也基于这条主干分支进行。

持续集成

CI = Continuous Integration 持续集成

马丁·福勒 Martin Fowler：
CI 是一种软件开发实践，团队成员频繁地将他们的工作成果集成到一起（通常每人每天至少提交一次，这样每天就会有多次集成），并且在每次提交后，自动触发运行一次包含自动化验证集的构建任务，以便尽早地发现集成问题。
核心理念是：越是痛苦的事情，就要越频繁地做。
工具是实践的载体，实践是工具的根基。

三个阶段：

• 第一阶段：每次提交触发完整的流水线。快速集成。
  前置条件：统一的分支策略，清晰的集成规则，标准化的资源池，足够快的反馈周期。
• 第二阶段：每次流水线触发自动化测试。质量内建。
  关注点：匹配合适的测试活动，树立测试结果的公信度，提升测试活动的有效性。
• 第三阶段：出了问题可以在第一时间修复。文化建立。
  人不是关键，建立机制才是关键。机制是一种约定，人们愿意遵守这样的行为，并且做了会得到好处。

极限编程 XP = ExtremeProgramming，是一种软件开发方法，作为敏捷开发的方法之一，目的在于通过缩短开发周期，提高发布频率来提升软件质量，改善用户需求响应速度。

自动化测试

测试三角形模型描述了从单元测试、集成测试到 UI 测试的渐进式测试过程。
自动化测试误报率 = 非开发变更引入的问题用例数量 / 测试失败的用例数量
测试误报率是体现自动化测试稳定性的一个核心指标。

内建质量

内建质量扭转了看待产品质量的根本视角，团队所做的一切不是为了验证产品存在问题，而是为了确保产品没有问题。
内建质量的两个核心原则：

• 问题发现得越早，修复成本就越低；
• 质量是每个人的责任，而不是质量团队的责任。

尽早发现问题，尽早解决。
Fail fast 快速失败。停止生产不是目的，及时发现问题和解决问题才是目的。
零缺陷，并不是说产品的 Bug 数量等于零，其实是一种质量观念，倡导全员质量管理，构建质量文化。每一个人在工作的时候，都要力争第一时间发现和解决缺陷。
质量是生产出来的，而不是测试出来的。

研发环节作为整个软件产品的源头，是内建质量的最佳选择。
核心目标不是为了通过质量门禁，而是为了质量提升。
实施步骤：

• 第一步：选择适合的检查类型。
• 第二步：定义指标并达成一致。
  度量指标分两个层面，一个是指标项，一个是参考值。
  指标项是针对检查类型所采纳的具体指标。
  参考值推荐静态指标+动态指标。
  静态指标是固定值。动态指标是以考查增量和趋势为主。
• 第三步：建立自动化执行和检查能力。
• 第四步：定义问题处理方式。
• 第五步：持续优化和改进。

技术债务

技术债务，是指团队在开发过程中，为了实现短期目标选择了一种权宜之计，而非更好的解决方案，所要付出的代价。这个代价就是团队后续维护这套代码的额外工作成本，并且只要是债务就会有利息，债务偿还得越晚，代价也就越高。
技术债务最直接的影响就是内部代码质量的高低。
三方面影响：

• 额外的研发成本
• 不稳定的产品质量
• 难以维护的产品

量化技术债务
在 SonarQube 中，技术债是基于 SQALE 方法计算出来的。
SQALE = Software Quality Assessment based on Lifecycle Expectations 基于生命周期期望的软件质量评估，是一种开源算法。
SQALE 评估代码质量的级别为 A、B、C、D、E。A 是最高等级，意味着代码质量水平最高。
技术债务比例 = 修复已有技术债务的时间 / 完全重写全部代码的时间

《Sonar Code Quality Testing Essentials》，代码的“七宗罪”：

类型	影响
不能均匀分布的复杂性	较高的圈复杂度需要更多的测试才能覆盖到全路径，导致潜在的功能质量风险。
重复代码	重复代码是最严重的问题，会导致潜在缺陷。另外，重复也会带来维护成本的增加。
不合适的注释	代码的注释没有明确标准。缺少关键环节的注释或者是注释难以理解，都会导致代码的可读性变差。
违反代码规范	影像团队基于共同的规范进行写作，会增加潜在的风险。
缺乏单元测试	单元测试不足会影响团队对代码的信心，增加重构成本，通过测试覆盖率对其进行度量。
缺陷和潜在的缺陷	缺陷和潜在缺陷是最直接影响代码质量的要素，要尽可能地发现并修复。
设计和系统架构	设计和系统架构受限于当时的资源条件，可能无法满足后续产品的发展需求，所以需要持续演进。

解决方法：共识，可见，止损，改善。
解决原则：让技术债务呈良性下降趋势。优先解决高频修改的问题。在新项目中启动试点。技术债务无法被消灭，也不要等到太晚。

环境管理

环境管理的挑战：环境种类繁多，环境复杂性上升，环境一致性难以保证，环境交付速度慢，环境变更难以追溯。

基础设施即代码：用一种描述性的语言，通过文本管理环境配置，自动化完成环境配置的方式。
典型的自动化环境配置开源管理工具，CAPS = Chef、Ansible、Puppet、Saltstacks

通过将所有环境的配置过程代码化，每个环境都对应一份配置文件，可以实现公共配置的复用。
环境的配置过程，完全可以使用工具自动化批量完成。

GitOps = 版本控制系统 + 基础设施即代码
核心在于通过代码化的方式来描述应用的部署环境和部署过程。
有利于环境配置的共享和统一管理。
无论采用什么技术，代码化管理的方式都是未来的发展趋势。

部署管理

四个核心的结果指标：
部署频率，部署失败率，前置时长，平均故障修复时长。

部署 Deploy，是一组技术实践，表示通过技术手段，将本次开发测试完成的功能实体（比如代码、二进制包、配置文件、数据库等）应用到指定环境的过程，包括开发环境、预发布环境、生产环境等。
部署的结果是对服务器进行变更，但是这个变更结果不一定对外可见。

发布 Release，是将部署完成的功能正式生效，对用户可见和提供服务的过程。更偏向一种业务实践。
发布的时机往往同业务需求密切相关。很多时候，部署和发布并不是同步进行的。

DevOps 模式下的质量思想：要在保障一定的质量水平的前提下，尽量加快发布节奏，并通过低风险发布手段，以及线上测试和监控能力，尽早地发现问题，并以一种最简单的手段来快速恢复。
一定的质量水平。
质量不再是测试团队自身的事情，而是整个交付团队的事情。

低风险发布手段：

• 蓝绿部署
• 灰度发布/金丝雀发布。实现机制之一：渐进式的滚动升级
• 暗部署。在用户不知道的情况下进行线上验证

线上测试和监控：
监控就是一种全量的测试
常用手段：

• 采用灰度发布、用户众测等方式，逐步观察用户行为并收集用户数据，以验证新版本的可用性是否符合预期
  埋点功能。
• 用户反馈
  用户运营和舆情监控系统。
• 使用线上流量测试
  流量镜像，GoReplay 工具

快速恢复：

• 阿里的开源工具 Arthas
• 向前修复和向后回滚
  向前修复：快速修改代码并发布一个新版本上线。
  向后回滚：将系统部署的应用版本回滚到前一个稳定版本。
• 服务降级和兜底策略
  服务降级：在流量高峰的时候，将非主路径上的功能进行临时下线，保证业务的可用性。
  兜底策略：常见的做法是缓存和兜底页面，以及前端比较流行的骨架屏等。

混沌工程

混沌工程是一门在分布式系统上进行实验的学科，目的是建立人们对于复杂系统在生产环境中抵御突发事件的信心。
混沌工程不是为了制造问题，而是为了揭示问题。

尽可能在这些故障和缺陷发生之前，通过一系列的实验，在真实环境中验证系统在故障发生时的表现。
故障演练：针对以往发生过的问题进行有针对性地模拟演练。
从业务层面来说，面对多变的环境因素，完善的服务降级预案和系统兜底机制也是必不可少的。适当地引入排队机制。

混沌工程的原则：

• 建立稳定状态的假设
  参考指标：

  指标类型	指标示例
  业务核心指标	用户数、活跃用户数、新增用户数、订单量、GMV、平均客单价、转化率、订单成功率、订单取消率、订单退货率、商品和商家数量
  业务访问指标	UV、PV、点击率、首页到达率、商品到达率、评论到达率
  用户体验指标	用户满意度、用户投诉数量、用户反馈数量、订单好评率、订单差评率
  系统指标	QPS、TPS、CPU使用率、CPU负载、内存使用率、网络连接数、平均响应时长、404数量

• 真实世界的事件
  投入产出比最高的就是选择重要指标（比如设备可用性、网络延迟，以及各类服务器问题），进行有针对性地实验。

• 在生产中试验
  要求实验范围可控，并且具备随时停止实验的能力。如果系统没有为弹性模式做好准备，就不要开启生产实验。

• 持续的自动化实验
  自动化是所有重复性活动的最佳解决方案。

• 最小的影响范围

正向度量

对于 IT 交付，DevOps 希望做到的是持续、快速和高质量的价值交付。

好的指标一般具备四种特性：明确受众、直指问题、量化趋势、充满张力。
好的指标应该是可以衡量的，是可以通过客观数据来自证的；向上可以归并到业务结果，向下可以层层分解到具体细节。

DevOps 度量的五条原则：
全局指标优于局部指标，综合指标优于单一指标，结果指标优于过程指标，团队指标优于个人指标，灵活指标优于固化指标。

DevOps度量指标：

• 交付效率
  • 需求前置时间：从需求提出到完成整个研发交付过程，并最终上线发布的时间。
    需求侧，从需求提出、分析、设计、评审到就绪的时长
    业务侧，研发排期、开发、测试、验收、发布的时长。
  • 开发前置时间：从需求进入排期、研发真正动工的时间点开始，一直到最终上线发布的时长。
• 交付能力
  • 发布频率：单位时间内的系统发布次数。原则上发布频率越高，代表交付能力越强。
  • 发布前置时间：研发提交一行代码到最终上线发布的时间。
  • 交付吞吐量：单位时间内交付的需求点数。
• 交付质量
  • 线上缺陷密度：单位时间内需求缺陷比例。即平均每个需求所产生的缺陷数量；缺陷越多，说明需求交付质量越差。
  • 线上缺陷分布：所有缺陷中的严重致命等级缺陷所占的比例。比例数值越高，说明缺陷等级越严重。。
  • 故障修复时长：从有效缺陷提出到修复完成并上线发布的时间。

开启度量工作的步骤：

• 第 1 步：细化指标
• 第 2 步：收集度量数据
• 第 3 步：建立可视化平台
• 第 4 步：识别瓶颈并持续改进

细化的交付指标
指标维度：交付质量

指标名称	线上缺陷密度	缺陷分布	故障修复时长
指标描述	单位时间内需求缺陷比例（单位需求缺陷数量)	严重致命等级缺陷占比	有效缺陷提出到修复的周期
指标级别	高	高	高
指标类型	结果指标	结果指标	结果指标
数据来源	需求管理平台、缺陷管理平台	缺陷管理平台	缺陷管理平台、质量管理平台
计算公式	=∑线上P4级别以上缺陷数/2统计周期内上线发布需求个数	=∑严重致命等级缺陷数量/2统计周期内所有级别缺陷数量	=故障修复时间-故障识别时间
参考值	<2‰	<5%	< 60min
使用场景	产品研发度量报告、产品研发沟通月会、度量平台质量视图	产品研发度量报告、产品研发沟通月会、度量平台质量视图	产品研发度量报告、产品研发沟通月会、度量平台质量视图
目标受众	全体产研成员	全体产研成员	全体产研成员
负责团队	质量管理组	质量管理组	质量管理组

度量的真正目的是团队效率的提升和业务的成功。
只有通过度量激起团队自发的改进意愿，提升团队改进的创造性和积极性，才是所谓的“正向度量”。

持续改进

始终能够找到新的突破，持续追求更好的状态。
构建持续改进的核心，就在于构建一个学习型组织。

质量管理大师戴明博士，戴明环 PDCA = Plan 计划, Do 实施, Check 检查, Action 行动

平台工具

平台建设

当企业决定引入 DevOps 工具时，有三种选择：直接使用开源工具；采购商业工具；自己研发工具。

企业 DevOps 平台建设的三个阶段：

• 阶段一：从无到有
  引入开源工具和商业工具，快速补齐现有的能力短板。
  能力短板：当前交付工具链体系中缺失的部分，尤其是高频操作，或者是涉及多人协作的部分，比如需求管理、持续集成等。

  选择主流工具：
  需求管理工具 Jira；
  知识管理工具 Confluence；
  版本控制系统 GitLab；
  持续集成工具 Jenkins；
  代码质量工具 SonarQube；
  构建工具 Maven/Gradle；
  制品管理 Artifactory/Harbor；
  配置管理工具 Ansible；
  配置中心 Apollo；
  测试工具 RF/Selenium/Appium/Jmeter/TestNG；
  安全合规工具 BlackDuck/Fortify；
  ……

• 阶段二：从小到大
  使用半自建工具和定制商业工具，来解决自己的问题。
  半自建工具：大多数情况下，仍是基于开源工具的二次开发，或者是对开源工具进行一次封装，在开源工具上面实现需要的业务逻辑和交互界面。
  注意事项：设计时给扩展留出空间；实现时关注元数据治理。

• 阶段三：从繁到简
  使用整合工具来化繁为简，统一界面，简化操作，有效度量。
  企业工具平台治理/平台化治理工作的建议：找到软件交付的主路径；区分平台和工具，让平台脱颖而出。
  打造自服务的工具平台。
  自服务：用户可以自行登录平台实现自己的操作，查看自己关心的数据，获取有效的信息。

指导平台建设的核心理念：“四化”：

• 标准化：一切皆有规则，一切皆有标准
• 自动化：干掉一切不必要的手工操作环节，能一键完成的，绝不操作两次
• 服务化：面向用户设计，而不是面向专家设计，让每个人都能在没有外界依赖的前提下，完成自己的工作
• 数据化：对数据进行收集、汇总、分析和展示，让客观数据呈现出来，让数据指导持续改进

产品设计

无论什么产品，其实都是为了解决一群特定的人在特定场景的特定问题。

产品设计体验的五个层次：

• 战略存在层
  始终着眼于那些长久不变的事物之上，即“多、快、好、省”。
  作为DevOps 产品战略定位的永远不变的东西：效率、质量、成本、安全。
  产品的任何功能都是要为战略服务的。
• 能力圈层
  产品化：将一个战略或者想法通过产品分析、设计、实验并最终落地的过程。
  零和游戏：所有玩家资源总和保持固定，只是在游戏过程中，资源的分配方式发生了改变。
  主航道和护城河理论：主航道，是产品的核心能力，直接反射了产品战略的具体落地方式。护城河是产品的不可替代性，或者是为了替代产品需要付出的高额代价。
• 资源结构层
  核心竞争力即对资源的整合和调动能力。
• 角色框架层
  不要让你的产品只有专业人士才会使用。
  产品应该提供抽象能力屏蔽很多细节，而不是暴露很多细节。好的产品自身就是使用说明书。
• 感知层
  建议：多跟前端工程师交流，多学习一些基本的设计原则，如一致、反馈、效率、可控。

持续交付平台

流水线是持续交付中最核心的实践，也是持续交付实践最直接的体现。

现代流水线设计的十大特性：

• 特性一：打造平台而非能力中心
  流水线平台是唯一一个贯穿软件交付端到端完整流程的平台。
  流水线的主要作用是驱动软件交付过程的效率提升和状态可视化。
  正确的做法：将持续交付流水线平台和垂直业务平台分开，并定义彼此的边界。

  流水线平台只专注于流程编排、过程可视化，并提供底层可复用的基础能力。比如运行资源池、用户权限管控、任务编排调度流程等等。
  流水线平台仅作为任务的调度者、执行者和记录者，不需要侵入垂直业务平台内部。

  垂直业务平台：单一专业领域的能力平台，比如自动化测试平台、代码质量平台、运维发布平台等等，是软件交付团队日常打交道最频繁的平台。
  垂直业务平台专注于专业能力的建设、一些核心业务的逻辑处理、局部环节的精细化数据管理等。
  垂直业务平台可以独立对外服务，也可以以插件的形式，将平台能力提供给流水线平台。

• 特性二：可编排和可视化
  流程可编排能力：用户可以自行定义软件交付过程的每一个步骤，以及各个步骤之间的先后执行顺序。
  编排的前提是系统提供了可编排的对象，一般称为原子。
  原子：一个能完成一项具体的独立任务的组件；组件具备一定的通用性，尽量与业务无关。

• 特性三：流水线即代码 Pipeline As Code
  比如Jenkins 2.0 中引入的 Jenkinsfile。

• 特性四：流水线实例化
  流水线需要支持参数化执行。
  流水线的每一次执行，都是一个实例化的过程。
  流水线需要支持并发执行能力。

• 特性五：有限支持原则
  流水线的设计目标，应该是满足大多数、常见场景下的快速使用，并提供一定程度的定制化可扩展能力，而不是满足所有需求。
  用户的差异化诉求，可以在平台中提供一些通用类原子能力，比如执行自定义脚本的能力、调用 HTTP 接口的能力、用户自定义原子的能力等等。

• 特性六：流程可控
  事件触发。比如Gitlab Webhook。

• 特性七：动静分离配置化
  动静分离是一种配置化的实现方式。
  将需要频繁调整或者用户自定义的内容，保存在一个静态的配置文件中。系统加载时通过读取接口获取配置数据，并动态生成用户可见的交互界面。
  设计标准化的系统的最佳实践是定义一个通用的数据结构。

• 特性八：快速接入
  提供插件机制，实现平台能力的接入。
  接入成本的高低，直接影响了平台能力的拓展；流水线平台支持的能力多少，就是平台的核心竞争力。
  轻量化的平台接入方法：自动化生成平台关联的原子代码。

  外部平台打通的两种类型：

  • 平台方提供本地执行的工具。类似 SonarQube 的 Scanner 方式，通过在本地调用该工具，实现相应的功能。
  • 通过接口调用的方式。实现平台与平台间的交互，调用的实现过程有同步和异步两种模式。

  流水线平台需要定义一套标准的接入方式。
  以接口调用类型为例，接入平台需要提供一个任务调用接口、一个状态查询接口以及一个结果上报接口。

  • 任务调用接口：用于流水线触发任务。由接入平台定义和实现。
  • 状态查询接口：用于流水线查询任务的执行状态，获取任务的执行进度。由接入平台定义和实现的，返回的内容包括任务状态、执行日志等。
  • 数据上报接口：用于任务将执行结果上报给流水线平台进行保存。由流水线平台定义，并提供一套标准的数据接口给到接入方。

• 特性九：内建质量门禁
  在流水线平台上，要完成质量规则制定、门禁数据收集和检查、门禁结果报告的完整闭环。

  策略模式的核心就在于面向接口而非面向过程开发，通过实现不同的接口类，来实现不同的检查策略。

• 特性十：数据聚合采集
  上报数据的颗粒度，原则就是满足用户对最基本的结果数据的查看需求。

数据度量平台

要解决的核心问题是软件研发过程可视化。

度量平台建设的思路：

• 事前：指标共识
  度量指标是数据度量平台的基础。
  比如开发交付周期指标的描述是：从研发在需求管理平台上将一个任务拖拽到开始的开发阶段起，一直到这个任务变成已发布状态为止的时间周期。
• 事中：平台建设
  数据获取：
  • 挑战一：大量数据源平台对接
    插件化，实现数据采集器。
  • 挑战二：海量数据存储分析
    数据度量平台一般都会保存元数据和加工数据。
    元数据：采集过来的、未加工过的数据。建议：非结构化数据存储的数据库，支持分布式存储系统 - HBase
    加工数据：经过数据清洗和数据处理的数据。建议：关系型数据库 - MySQL
  • 挑战三：度量视图的定制化显示
    可以利用现有的前端组件来实现可视化界面展示。
• 事后：规则落地
  尽量实现自动化操作，而不是依赖于人的自觉性。
  度量的目的是持续改进。

平台产品研发

• 项目启动
  系统方案选型；建立协作机制。
  建立固定的沟通机制就非常重要。

  重点关注的几件事情：

  • 明确项目目标，树立团队的信心
  • 沟通开发模式和技术架构选型，以快速开发和简单上手为导向
  • 建立沟通渠道，保持高频联系
  • 识别项目的技术风险，提前开启专项预研

• 开发策略
  环境容器化。

• 开发协作流程
  内部“3-2-1”原则：

  • 3：创建任务三要素
    有详细的问题说明和描述
    有清晰的验收标准
    有具体的经办人和迭代排期
  • 2：处理任务两要素
    在开发中，代码变更要关联 Jira 任务号
    在开发完成后，要添加 Jira 注释，说明改动内容和影响范围
  • 1：解决任务一要素
    问题报告人负责任务验收关闭

• 产品运营策略
  打广告，如流量高的地方，技术分享上宣传。

• 团队文化建设

  • 让专业的人做专业的事情
  • 抓大放小，适当地忽略细节

开源工具

对于持续交付工具链体系，工具的连通性是核心要素。

需求管理 - Jira
代码管理 - GitLab
代码质量 - SonarQube
环境管理 - Kubernetes

JNLP = Java Network Launch Protocol，是一种通用的远程连接 Java 应用的协议方式。

流水线工具对比：

工具	易用性	流水线设计	插件生态	扩展性	适用场景
Jenkins	低	Groovy代码（支持描述式语法和可视化编辑）	高	低	各种规模团队和各种产品形态，需要有专人维护
Jenkins X	低	Yaml	高	高	云原生开发场景，遵循开发流程，小规模试点团队，不建议生产使用
GitLab CI	中	Yaml	低	中	中大型团队，不建议小型团队使用（系统维护成本高）
GitHub Actions	中	Yaml（支持可视化编辑）	高	中	开源产品或初创产品，不适合企业级应用（商业化问题）
Drone	高	Yaml	中	高	中小型团队，云原生开发场景

Cloud native computing uses an open source software stack to deploy applications as microservices, packaging each part into its own container, and dynamically orchestrating those containers to optimize resource utilization.
云原生使用一种开源软件技术栈来部署微服务应用，将每个组件打包到它自己的容器中，并且通过动态编排来优化资源的利用率。

云原生应用的12要素：

1. 基准代码∶一份基准代码、多份部署。
2. 依赖：显式声明依赖关系。
3. 配置：在环境中存储配置。
4. 后端服务：把后端服务当作附加资源。
5. 构建、发布、运行∶严格分离构建、发布和运行。
6. 进程：以一个或多个无状态进程运行应用。
7. 端口绑定∶通过端口绑定提供服务。
8. 并发：通过进程模型进行扩展。
9. 易处理∶快速启动和优雅终止，最大化健壮性。
10. 开发环境与线上环境等价∶尽可能保持开发、预发布、线上环境相同。
11. 日志：把日志当作事件流。
12. 管理进程：把后台管理当作一次性进程运行。

云时代，一切皆服务。
Jenkins X + Tecton：

1. 自动化生成依赖的配置文件
   Dockerfile：用于生成 Docker 镜像
   Jenkinsfile：应用关联的流水线配置
   Helm Chart：把应用打包并部署运行在 Kubernetes 上的资源文件
   Skaffold：用于在 Kubernetes 中生成 Docker image 的工具

2. 自动化流水线过程
   用到的技术：

   • 流水线即代码。只有代码化的流水线配置才有可能自动化。
   • 流水线的抽象和复用。以 Jenkinsfile 为例，大多数操作应该提取到公共库 shared library，以提升抽象水平和能力复用。
   • 流水线的条件判断。对于同一条流水线来说，根据不同的条件，可以实现不同的执行路径。

3. 自动化多环境部署
   将云原生应用部署在 Kubernetes 上时，所有依赖都是环境中的资源。

4. 使用云原生流水线
   Jenkins X 提供了上层抽象，通过 YAML 文件的形式描述整个交付过程。
   Tekton 提供了最底层的能力。
   在后台，Jenkins X 将这个文件转换成 Tekton 需要使用的 CRD 资源并触发 Kubernetes 执行。
   用户看起来还是在使用 Jenkins，实际上，流水线的执行引擎已经从原来的 JVM 变成了现在 Kubernetes。流水线的执行和调度由 Kubernetes 来完成，整个过程中每一步的环境都是动态初始化生成的容器，所有的数据都是通过外部存储来保存的。

   CRD = Custom Resource Definition 自定义资源定义

云原生关键技术：容器，容器编排，微服务、服务网络，不可变基础，声明式 API，DevOps。

不可变基础设施是现代运维的基石，
容器编排Kubernetes是整个云原生的基石，
容器是Kubernetes的底层引擎，Docker是应用最广的容器工具，
微服务是Docker的好搭档，
服务网格是微服务的辅助，建立在Kubernetes上的针对请求的扩展功能，
声明式API是Kubernetes的编码方式。

https://digital.ai/learn/devsecops-periodic-table/