淘宝联盟自己做网站,百度竞价排名推广,软件项目报价,做网站用cms好吗DevOps实践指南 25. 附录附录 1 DevOps 的大融合精益运动敏捷运动Velocity 大会运动敏捷基础设施运动持续交付运动丰田套路运动精益创业运动精益用户体验运动Rugged Computing 运动 附录 2 约束理论和核心的长期冲突附录 3 恶性循环列表附录 4 交接和队列的危害附录 5 工业安全… DevOps实践指南 25. 附录附录 1 DevOps 的大融合精益运动敏捷运动Velocity 大会运动敏捷基础设施运动持续交付运动丰田套路运动精益创业运动精益用户体验运动Rugged Computing 运动 附录 2 约束理论和核心的长期冲突附录 3 恶性循环列表附录 4 交接和队列的危害附录 5 工业安全误区附录 6 丰田安灯绳附录 7 软件包产品附录 8 事后分析会议附录 9 猿猴军团附录 10 上线时间透明化 26. 术语 25. 附录
附录 1 DevOps 的大融合
我们认为 DevOps 正在得益于一场令人难以置信的管理实践大融合各种实践相互促进和衔接在一起并形成了一种独特的实践集合它能对组织的软件开发转型和 IT 产品或服务交付模式的转型产生极大的帮助。
John Willis 称之为“DevOps 的大融合”。下面尽量按时间顺序介绍这次大融合里的各种元素。 请注意这里并不详细介绍它们而只是概要地介绍各种思维的演进以及发生在它们之间的难以置信的链接最终导致了 DevOps 的应运而生。 精益运动
精益运动始于 20 世纪 80 年代衍生自丰田生产系统TPS。TPS 包括价值流映射、看板和全面生产维护等。
精益的两个主要原则是
(1) 坚信前置时间把原材料转换为成品所需的时间是提升质量、客户满意度和员工幸福感的最佳预测指标(2) 小批量尺寸是短前置时间的一个最佳预测指标理论上讲最理想的批量尺寸是“单件流”即“1×1”的流库存为 1批量尺寸为 1。
精益原则专注于为客户创造价值要求系统性思考持之以恒拥抱科学思维创建流和拉动而不是推动的模式从源头保证质量以谦逊为导向尊重每一个人。
敏捷运动
始于 2001 年。“敏捷宣言”是由 17 位软件开发领域的顶尖大师编写的目的是掀起一场推广轻量级软件开发方法如 DP 和 DSDM-动态系统开发方法的运动用敏捷替代瀑布式等重量级软件开发过程以及替代统一软件开发过程RUP这样的方法论。
它的一个关键原则是“频繁地交付可工作的软件交付周期可以是数星期也可以是数月推荐更短的周期。”另外还有两个原则一个是小型的、自我激励的团队应工作在高度信任的模式下一个强调小批量尺寸。敏捷还和一系列的工具和实践相关如 Scrum、站会等。
Velocity 大会运动
从 2007 年开始由 Steve Souders、John Allspaw 和 Jesse Robbins 等人组织并发起了 Velocity大会目的是为 IT 运维和网站性能调优人员提供一个聚首的机会。在 2009 年的 Velocity 会议上John Allspaw 和 Paul Hammond 做了主题为“每日 10 次部署Dev 和 Ops 在 Flickr 的协作”的演讲。
敏捷基础设施运动
在 2008 年的多伦多敏捷会议上Patrick Debois 和 Andrew Schafer 主持了一场名为“羽毛之鸟”专题研讨探讨如何将敏捷原则应用于基础设施而不仅限于应用程序代码。他们很快得到了一些志同道合的思考者的响应其中也包括 John Willis。后来Patrick 又深受 John 和 Hammond的“每日 10 次部署Dev 和 Ops 在 Flickr 的协作”演讲的鼓舞于 2009 年在比利时的根特市举办了第一次 DevOpsDays 活动创造了“DevOps”这个词。
持续交付运动
在持续构建、测试和集成等开发实践的基础上Jez Humble 和 David Farley 发展出了持续交付的理念其中包括确保将代码和基础设施始终处于可部署状态的“部署流水线”并且确保所有提交到主干的代码都能安全地部署到生产环境里。
这个想法最早是在 2006 年的敏捷大会上公布于众的Tim Fitz 在他的一篇名为“持续部署”的博文中完善了这个概念。
丰田套路运动
在 2009 年Mike Rother 编写了《丰田套路转变我们对领导力与管理的认知》一书书中描述了他对丰田 20 年研究的收获。这期间他理解了丰田生产系统TPS的因果机制并对其作了综述。书中介绍了“丰田成功背后隐形的管理例程和思维模式及其不断改进和调整……以及其他公司如何在他们的组织中践行类似的例程和思维模式”。
他的结论是精益社区错失了与所谓的“改善套路”相关的最重要的实践。 他解释说每个组织都有工作日程丰田成功的关键因素是改进了工作习惯并将其植入到组织里每个人的日常工作中。丰田套路建立了一种迭代、增量、科学的解决问题的方法追求共同的企业目标。
精益创业运动
在 2011 年Eric Ries 编写了《精益创业新创企业的成长思维》一书总结了他在一家硅谷创业公司 IMVU 的经验教训。这本书的核心思想基于 Steve Blank 的《四步创业法》一书和持续部署技术。Eric Ries 还给出了相关实践并定义了一些术语包括最小化可行产品MVP、构建 - 度量 - 学习的循环以及很多持续部署的技术模式。
精益用户体验运动
在 2013 年Jeff Gothelf 撰写了《精益设计设计团队如何改善用户体验》一书其中描写了如何改进“模糊前端”并解释了产品经理如何在投入时间和资源以前制定业务假设实验籍此获取关于业务的信心。有了精益设计全面优化业务假设、功能开发、测试、部署和为客户发布服务的工具就齐了。
Rugged Computing 运动
2011 年Joshua Corman、David Rice 和 Jeff Williams 深入考察了软件开发周期晚期进行应用程序和环境安全加固的无效性。 根据考察结果他们提出了名为 Rugged Computing 的哲学旨在构建包含稳定性、可扩展性、可用性、生存性、可持续性、安全性、可支持性、可管理性和防御性等的非功能性需求框架。
DevOps 强调高频率发布可能会给质量保证QA和信息安全Infosec带来巨大的压力因为当部署频率从每月或每季度一次提升到每天数百或数千次时信息安全或质量保证的工作周期就不再是两周一次了。Rugged Computing 运动假设当前的多数信息安全防护措施是没用的。
附录 2 约束理论和核心的长期冲突
约束理论主要讨论核心冲突云通常称为“C3”的作用。图 A-1 是 IT 的冲突云示意图。 在 20 世纪 80 年代在制造业里核心的长期冲突非常普遍。所有工厂经理都有两项重要的业务目标提高销量降低成本。 问题是为了保持销量库存就要增加以确保始终能满足客户需求。
然而要降低成本就应该减少库存以确保资金没有占用在在制品上。在制品指按客户订单生产的但还不能立即发货的产品。
应用精益原则能解决以上冲突例如减小批量尺寸减少在制品数量以及缩短和放大反馈回路。 这样工厂的生产率、产品质量和客户满意度都会得到显著提高。
DevOps 工作模式背后的原理与制造业变革的原则是相同的那就是优化 IT 价值流将业务需求转化成为向客户提供价值的能力和服务。
附录 3 恶性循环列表
《凤凰项目》中描绘的恶性循环如表 A-1 所示。
附录 4 交接和队列的危害
队列等待时间会随着交接次数的增加而延长因为队列是由于交接而产生的。图 A-2 显示了一个工作中心资源的繁忙程度与等待时间的关系。渐变的曲线显示了为什么“一个 30 分钟的简单变更”通常却需要几周的时间才能完成。某些工程师和项目组若过于繁忙通常就会变成瓶颈。当一个项目组满负荷时任何需要它完成的任务都会被淹没在队列里如果没有人进行催促或提高优先级该任务将永远也不能完成。 在图 A-2 中横坐标表示在一个项目组里某特定资源的繁忙百分比纵坐标是等待时间或者更准确地说是队列长度。曲线的形状表明在资源利用率超过 80%以后等待时间会急速攀升到顶点。 附录 5 工业安全误区
对复杂系统几十年的研究表明人们的处理策略都是基于几个误区
误区 1人为错误是意外和事故最主要且唯一的根源。误区 2如果人遵守了既定的规程那么系统就是安全的。误区 3安全性可以通过设置权限和防护来提升。保护层次越多安全性就越高。误区 4事故发生的根本原因“真相”可以通过事故分析来确定。误区 5事故调查就是识别事实和原因之间的逻辑和关联关系。误区 6安全性总是优先级最高的不容降低。
误区与真相之间的区别如表 A-2 所示。
附录 6 丰田安灯绳
许多人问如果安灯绳每天被拉了 5000 次那么生产工作怎么会完成呢确切地说并不是每个安灯绳都会导致整个装配线的停止。相反当安灯拉绳被拉下时监督那个工作中心的团队领导有 50 秒时间解决这个问题。如果在 50 秒内问题没解决没有装配完毕的车辆就将越过地板上画的那条线然后这条装配线才会停止见图 A-3。
附录 7 软件包产品
为了将复杂的软件包产品COTScommercial off-the-shelf software如 SAP、IBM WebSphere、Oracle WebLogic也纳入版本控制我们可能不得不去掉厂商提供的图形化的点击操作模式的安装工具。为此需要了解厂商提供的工具的用途还需要一个干净的服务器安装图片需要比对文件系统并将新增的文件纳入版本控制。将那些与安装环境无关的文件都放在同一个位置“基础安装”将环境有关的文件放入各自的目录“测试”或者“生产”。通过这种方式软件安装操作就变成了版本控制的操作可视化效果和可重复性都更好了速度也提升了。
我们可能还要转换应用配置设置把它们也纳入版本控制。例如可以将存储在数据库里的应用配置转换为 XML 文件XML 文件也可以转换为应用配置。
附录 8 事后分析会议
事后分析会议的议程样例如下。
首先由会议主持或协调人做会议启动发言强调这个会议是对事不对人的事后分析会议我们的重点不是发生过的事也不会去推测“本来会怎样”或“本来有可能怎样”。协调人可以宣读来自 Retrospective.com 网站的“回顾基本指导原则”。此外协调人将提醒大家得出的任何对策都一定要分配到具体的人如果纠正措施不能成为这个会议后的首要任务那么这就不是纠正措施。这是为了防止会议上讨论了一系列好想法可是永远也不付诸行动。在会议期间要对事故完整的时间表达成一致的认识。包括在什么时间、是谁发现的问题通过什么途径发现的问题例如自动监测、手动检测、客户反馈在什么时间服务得到了彻底的恢复等等。我们还将在事故发生期间所有的外部讨论归纳到时间表中。提到“时间表”大家可能会理解为调查问题并解决问题的步骤。实际上特别是在复杂的系统中导致事故发生的事件可能会有许多并且将会采取多种解决问题的故障排查方案和措施。 在这项活动中我们试图记录所有的事件和所有参与者的观点并尽可能地建立出各种可能的因果关系的假设。事后分析团队将列出所有造成事故的人为因素和技术因素并将其归类如“设计决策”“修复”“发现的问题”等。团队将使用头脑风暴和“十万个怎么样”方法对他们认为特别重要的诱因进行深入挖掘从而探索更深层次的诱因。所有的观点都应当得到包容和尊重不允许争论或否认其他人已经确认的诱因。会议协调人特别需要注意的是必须确保做这项活动的时间充足而且团队不应尝试去异存同不要试图确定出一个或几个“根本原因”。与会人员要就会后首要任务清单达成一致意见。清单所列内容需要集思广益并选择能防止问题复发的任务或者能更快发现问题并复原的任务。列表还可以包括改进系统的其他方式。 我们的目标是确定实现预期结果的最小增量步骤而不是“大爆炸”式的变更因为那不仅需要更长的实施时间还会推迟改进。我们还会生成一份单独的列表列出那些优先级较低的任务并为其分配一个负责人。如果将来发生类似的问题就可以基于这些任务制定对策。与会人员还要讨论事故的衡量指标和事故对组织造成的影响。例如我们可以使用下列指标来定量描述事故。 事件严重性这个问题的严重程度。严重性会直接影响服务和客户。总停机时间服务完全不可用的时间。检测时间发现问题所需的时间。解决时间知道问题以后恢复服务所用时间。
Etsy 公司的 Bethany Macri 是这么总结的“在事故分析中对事不对人并不意味着没有人承担责任而是想了解在什么情况下允许人员执行变更或者谁引入的问题。没有责难就没有顾虑没有了顾虑就可以坦诚相待。”
附录 9 猿猴军团
在 2011 年 AWS 的美东服务中断事故之后Netflix 曾就如何自动处理系统故障讨论过多次。一个名为“捣乱猴”的服务就是这些讨论的结果。
此后捣乱猴逐渐演变成了一套全系列的工具内部称之为“Netflix 猿猴军团”用来模拟灾难的不同程度
捣乱大猩猩模拟整个 AWS 可用区域ZA的故障。捣乱金刚模拟整个 AWS 地区Region的故障如北美或欧洲。延迟猴子在其 RESTful 客户端服务器的通信层人为引入的延迟或停机以模拟服务降级并确保相关服务正常工作。一致性猴子查找并关闭不符合最佳实践的 AWS 实例例如实例不属于任何自动伸缩组或服务目录中没有值班工程师的电子邮件地址。医生猴子检查每个运行的实例找到不健康的实例如果负责人没有及时修复就主动关闭实例。看门猴子确保他们的云环境没有混乱和浪费搜索未使用的资源并处理。安全猴子一致性猴子的升级版找到并终止有安全违规或漏洞的实例例如 AWS 安全组配置错误。
附录 10 上线时间透明化
Lenny Rachitsky 这么陈述他所谓的“上线时间透明化”的优势。
(1) 支持的成本下降。因为用户能够自己识别系统里的问题无需打电话或发电子邮件给支持部门。用户不再需要猜测是本地问题还是全局性问题并且可以在跟运维抱怨之前更快速地定位问题。(2) 在宕机期间能与客户更良性沟通。利用互联网传播的优势而不是电子邮件、电话这种一对一性方式能实现更好的沟通效果。在客户沟通上省事了就有更多时间来解决问题。(3) 让客户在发生宕机事故时有明确的可寻求帮助的途径不必再四处搜索论坛、Twitter 或博客。(4) 信任是所有 SaaS 应用成功的基石。客户将自己的业务和生计都押宝在了你的服务或平台上。现有和潜在的客户都需要信任服务。他们想确保当服务出现问题时自己也有知情权。让他们实时了解意外事件是建立信任的最佳方法向客户隐瞒实情不再可取。(5) 认真负责的 SaaS 提供商早晚都会提供公开的健康度仪表板这只是时间问题因为用户有这样的需求。
26. 术语
DOP Handbook Glossary
英文中文A/B TestingA/B 测试Acceptance Stage验收阶段Acceptance Test-Driven Development (ATDD)验收测试驱动开发Acceptance Test验收测试Accident事故Affinity亲和Agile敏捷Andon Cord安灯绳Anomaly Detection Technique异常探测技术Antifragility抗脆弱性Application Deployment应用部署Artifact Management构件制品库管理Artifact制品Automated Test自动化测试Automation自动化Backlog待办事项列表Bad Apple Theory坏苹果理论Bad Path坏路径Batch Size批次尺寸、批量大小Blame指责Blameless Post Mortem不指责的事后分析Blamelessness免责Blue-Green Deployment蓝绿部署Blue-Green Deployment Pattern蓝绿部署模式Branching Strategy分支策略Brownfield棕地Build构建Business Value业务价值Canary Release金丝雀发布Canary Release Pattern金丝雀发布模式Card卡片Change Category变更类别Change Schedule变更计划Cloud Computing云计算Cloud Configuration File云配置文件Cluster Immune System Release Pattern集群免疫系统发布模式Code Branch代码分支Code Review Form代码审查表Codified Nfr成文的非功能需求Collaboration协作Commit Stage提交阶段Commit Code提交代码Compliance Requirement合规性要求Compliance Checking合规性检查Compliancy Officer合规检测官Configuration Management配置管理Container容器Continuous Deployment持续部署Continuous Integration持续集成CIContinuous Delivery持续交付CDConways Law康威定律Cycle Time周期时间Defect Tracking缺陷跟踪Definition Of Done (DoD)完成的定义Dev Ritual开发惯例Developer开发人员Development开发Devops TransformationDevOps 转型Downstream/Upstream下游/上游Downwards Spiral恶性循环E-Mail Pass-Around电子邮件轮查Expand/Contract Pattern扩张/收缩模式Exploratory Test探索性测试Fast Feedback快速反馈Feature特性Feature Flag特性标志Feature Toggle特性开关Feedback/Feedback Loop反馈/反馈回路Feedforward/Feedforward Loop前馈/前馈回路Flow流动Gated Commit门控提交Gaussian Distribution高斯分布Green Build绿色构建Greenfield绿地Handoff交接Hand-Off Readiness Review交接就绪评审Happy Path愉快路径Hypothesis-Driven Development假设驱动开发Incident事件Information Radiator信息辐射器Infosec信息安全Infrastructure Automation基础架构自动化Infrastructure As Code基础架构即代码Integration Tests集成测试I-Shaped, T-Shaped, E-ShapedI 型、T 型、E 型Iteration迭代Itsm (It Service Management)IT 服务管理Ji-Kotei-Kanketsu (JKK)质量检查JKKJust Culture公正文化Just-In-Time (JIT)准时制Kaizen (In Lean)改善Kaizen Blitz (Or Improvement Blitz)改善闪电战Signboard看板Kata套路Large Batch Size Merge大批量合并Latent Defect潜在缺陷Lauching Guidance发布指导Launch Readiness Review投产就绪评审Lead Time前置时间Lean精益Learning Culture学习文化Logging Level日志级别Loosely Coupled Architecture松耦合架构Micro-Service微服务Minimum Viable Product最小化可行产品Monitoring Framework监控框架Monolithic Application单体应用Monolytics单体应用MTTR平均恢复时间Non-Functional Requirement (NFR)非功能性需求Non-Functional Requirement (NFR) Testing非功能需求测试(Non) Ideal Testing Pyramid非理想测试金字塔模型One-Piece-Flow单件流Operations运维Operations Story运维故事Ops Liaison运维联络人Organisational Typology Model组织结构模型Organization Archetype组织原型Organizational Learning组织级学习Over-The-Shoulder观察者评审Package包Pair Programming结对编程Peer Review同行评审Pilot试点Pipeline流水线Plan-Do-Check-Act Cycle (PDCA Cycle)计划-实施-检查-改进循环戴明环Post-Mortem事后分析Process Time处理时间Product Owner产品负责人Pull Request Process拉动请求流程QA质量保证Reduce Batch Size降低批次尺寸Reduce Number Of Handoffs减少交接次数Regression Test回归测试Release Branch发布分支Release Manager发布经理Release Pattern发布模式Retrospective回顾Rhythm节奏Roll-Back回滚Sad Path不愉快路径Safety Culture安全文化Safety Conditions安全条件Scaling规模化ScrumScrumScrum MasterScrum MasterSecurity Testing安全测试Self Service Capability自服务能力Service Deployment服务部署Service Level Agreement (SLA)服务级别协议SLAShared Goal共同目标Shared Operations Team (SOT)共享运维团队Shared Version Control共享版本控制Single Repository单一存储库Smoke Testing冒烟测试Sprint冲刺StagingStagingStaging Environments, SIT准生产环境Stakeholder利益干系人Standard Deviation标准差Standard Operations标准运维Static Code Analysis静态代码分析Swarm聚集、聚焦、会诊、围观动词Swarming聚集System Of Engagement (SOE)交互系统System Of Records (SOR)记录系统Technical Debt技术债务Technology Adaption Curve技术适应曲线Technology Executive技术主管Telemetry遥测Test Coverage Analysis测试覆盖率分析Test Story测试故事Test-Driven Development测试驱动开发The Downward Spiral - TDS下行螺旋The Agile Manifesto敏捷宣言The Lean Movement精益运动The Simian Army: Chaos Gorilla Chaos Kong Conformity Monkey Doctor Monkey Janitor Monkey Latency Monkey Security Monkey猿猴军团可靠性监控服务 捣乱大猩猩 捣乱金刚 一致性猴子 医生猴子 看门猴子 延迟猴子 安全猴子The Three Ways三步工作法Theory Of Constraints约束理论Ticketing System工单系统Tightly-Coupled紧耦合Tool-Assisted Review工具辅助评审Tool工具Toyota Production System (TPS)丰田生产系统Toyoto Kata丰田套路Transformation Team转型团队Trunk主干User Story用户故事Value Stream Mapping价值流映射Value Stream价值流Velocity速率Version Control版本控制Virtualized Environment虚拟化环境Visible可视的Visualisation可视化Waste浪费Waste Reduction减少浪费Waterfall瀑布式WIP (Work In Progress / Process)在制品WIP Limit在制品限制Work Center工作中心
