DevOps基础-1.4-DevOps的十大实践

个人和组织发现了许多帮助它们实施DevOps的实践，但是其中并没有一个特别好的实践去做DevOps，这里提供10个在许多企业使用过的实践，给你参考和思考。

 

实践10：事故指挥系统

在IT领域，不好的事情发生在我们服务里，我们把这种事情叫做事故。许多学校的旧的事故管理流程似乎只能适用于大规模的事故。但是在现实生活中，会出现许多小事故，大事故还是比较少。

我在会议上看到的最喜欢的演讲之一是Brent Chapman的IT事件指挥部。我们可以从消防部分学习到什么？它解释了事件命令如何在现实世界中为紧急服务工作，并解释了相同的过程如何适用于IT，适用于小型和大型事故。我已经在许多商店进行ICS事故响应，效果很好。

Ps：任何情况下都需要有风险意识，在DevOps中，也可能发生事故，如果进行事故响应和处理是DevOps实践中需要考虑的一个因数。同样，经历过许多事故处理，你的DevOps经历就更加丰富。从整体思考角度来说，在DevOps实践中，有必要引入和使用事故指挥系统。

 

实践9：开发人员随叫随到

大都数IT组织都会安排人员值班，特别是运维团队，确保自己服务正常运行，运维人员需要随叫随到。毋庸置疑，解决一个问题有时候并没有那么容易。开发组也需要安排开发人员值班，这样就创建了一个快速的反馈循环。运维团队配合开发，通过日志和相关后续部署活动，快速解决线上问题。而不是挥霍时间，尝试去启动网络和服务器服务来解决问题。

Ps: DevOps本身也是一个产品，本身就是开发出来的，用来解决实际问题的，一旦出现了问题或者事故，需要开发人员随叫随到，立马解决问题。

 

实践8：状态页面

状态页面（status pages），服务宕机，说明出现了问题，这个是生活中的事实。在这些停电或者宕机期间，唯一能够提高客户满意度并保持信任的因素是沟通。就像Lenny Rachitsky的博客中倡导那样，线上透明的正常运行时间，创建公共状态页面，并在出现问题的时候，与服务用户进行及时和清晰的沟通。假设你使用了状态页面，会发生这样的场景：当问题出现，你就运行把运行的每一个服务都有一个状态页面。当然更新这个状态页面，用户可以收到问题通知，了解你在做什么。

Ps：这个状态页面，有点类似项目管理中的看板的作用。

 

实践7：blameless postmortems

几十年的工业安全研究已经证实了这一想法，即事故的根本原因，或者我们可以将人为错误作为失败的可接受原因。John Allspaw, Etsy公司的CTO，写了一篇这样的文章“Blameless Postmortems and A Just Culture”，介绍了如何检查这些失败并从中吸取教训，同时避免逻辑谬误。而不是，依靠替罪羊，让自己感觉良好，同上让情况变得更糟糕。

PS：出现了问题，就需要有责任人，没有什么好指责他人。问题已经发生，互相指责已经解决不了问题，分析问题，吸取教训，才是合理的做法。

 

实践6：嵌入式团队

在软件开发人员和运维人员之间最尖锐的矛盾就是，开发人员需要发布新代码，而运维人员想要服务稳定。在其中，彼此之间存在利益冲突。一种解决问题的办法就是，采取他们两个团队的共同领导的意见。这就是典型的拍桌子做出决定。另外一种解决办法就是，把团队重新组织，在一个开发组中嵌入一个运维工程师，让团队负责自己的所有工作。而不是，开发团队将升级请求丢到运维团队。采用开发团队中嵌入运维工程师，自己的工作自己团队处理，使大家有了共同的目标，即更新稳定的服务到生产环境。

 

实践5：云端

如果想要在云端实现DevOps，那么就要实现高度自动化以及基础设施能写成代码。使用云技术的最有说服力的理由，不是成本优化，而是云解决方案为您提供完全以API驱动的方式来创建和控制基础架构。这使你可以处理程序组件一样去对待基础设施结构。只要你能够设计新的部署策略或灾难恢复计划等，您就可以在不等任何人的情况下试用它。

PS：其实DevOps，就是说在云端进行的解决方案。举例一个简单例子，假如你在阿里云网页注册账号，然后选择了购买什么类型主机，你提交订单。阿里云后台就启动了关于这个订单的自动化部署活动，一旦部署好了，你就可以收到相关邮件。例如告诉你主机IP地址和root密码等。这个就是一个简单的处理用户订单的DevOps实例。

 

实践4：Andon Cords

经常在DevOps环境中进行快速版本发布。理想情况下，你写了可以捕获和验证大多数的功能的自动化脚本，但是测试还是不够完美。这个时候，就可以采用Andon Cords系统。这个是起源日本丰田公司，实现“立即暂停制度”，以即时解决质量问题（而不是下线返修），达到持续高品质地生产汽车的一种工业上的流程。

这个模式成了今天质量控制系统的基本组成部分，您可以在软件交付管道（Pipeline）中拥有相同的功能，这样您就可以暂停升级或部署以阻止错误传播到下游。

PS：这里提到了Pipeline，简单解释以下，在Jenkins中，最强大的功能就是Pipeline，不同的job都可以用Pipeline的形式串接起来。Pipeline是Groovy语言开发的。所有任何Job都可以通过Groovy语言来编写代码，去控制Job的行为。Pipeline的代码部分是DevOps中重点要实践和学习的部分。

 

实践3：依赖注入

在现代应用程序连接到它的外部服务（如数据库或重置服务等）时，它们是大多数运行时问题的根源。有一种称为依赖注入的软件设计模式，有时也称为控制反转，这主要关注松散耦合的依赖关系。在这种模式中，应用程序不应该知道它的外部依赖性。 相反，它们在运行时传递给应用程序。 这对于作为代码环境的基础结构中的良好应用程序非常重要。还一种服务发现设计模式也可以到达类似效果。

 

实践2：蓝/绿部署

软件部署。 它的工作方式只有一种，对吧。 我的意思是传统上，你取下服务器上的软件，升级它，重新启动，然后你甚至可以回滚方式执行此操作，因此，您可以保持系统的正常运行时间。但是，一种替代部署模式称为蓝/绿部署。 而不是在暂存环境中测试版本然后将其部署到生产环境并希望它工作，而是有两个相同的系统，蓝色和绿色。

PS：这个很好理解，第一种是直接在线上环境升级，第二种是在准生产环境升级，然后进行测试，没有问题就切换到线上环境，原来的线上环境撤下来，继续升级，最终切换到线上生产环境。DevOps也需要至少两套环境，测试环境和线上环境。

 

实践1：Chaos Monkey

Chaos Monkey是Netflix团队推出的一个工具，相关介绍: http://www.infoq.com/cn/news/2012/08/chaos-monkey.

旧式系统开发理论强调使系统的每个组件尽可能高度可用。这样做是为了实现最高的正常运行时间, 但这不起作用。从数学上来说，如果有5个组建，每一个组建的可用度是99%，那么这个软件的可用度是95%。

相反，您需要专注于使整个系统高度可靠，即使面对不可靠的组件。Netflix是新型技术管理领域的领先公司之一，为了确保他们正确地提供服务可靠性，他们发明了一款名为Chaos Monkey的软件。Chaos Monkey观看在亚马逊云中运行的Netflix系统，随机杀掉架构中运行实例和服务。这迫使开发人员和运维创建系统，以便为其服务设计弹性。而不是错误地认为他们的基础设施始终在运行良好状态。

作为一个DevOps小白的我们，先大概了解下这些实践内容就好，以后工作中遇到了，会自然而然加深印象和有更好的理解。