简单理解DevOps

简单理解DevOps

一、进入DevOps的-高速公路的三条车道

老一派的软件开大团队成员会包含业务分析员，系统架构师，前段开发者，后端开发者，测试员，等等。优化如敏捷和精益原则等的软件开发流程的关注点就在这些地方。比如，软件一旦达到可以生产的程度，就会发到系统工程师、发布工程师、DBA、网络工程师，安全专家这些运维人员的手上。这里该如何将Dev(开发)和（运维）之间的鸿沟给填平，这就是DevOps的主要关注点了。

DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产，将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。

你不应该重新招聘DevOps工程师，而且DevOps也不应该是一个IT的新部门。DevOps是一种文件，一种理念，且是和IT糅合成一整体的。世间没有加速进入到第二条车道，最终在第三条上高速行驶。

• 车道1 – 系统级别的整体效率考量是最主要的关注点，这超过对系统任何一个单独个体元素的考虑。
• 车道2 – 确保能提供持续不断的反馈循环，且这些反馈不被忽视。
• 车道3 – 持续的学习和吸取经验，不听的进步，快速的失败。

二、车道1 – 获取速度

1. 要采纳DevOps的原则，理解整个运作系统的重要性并对工作事项进行合适的优先级排序是组织首先要学的事情。在整个价值流中不能允许任何人产生瓶颈并降低整个工作流程。
2. 确保工作流程的不可中断是身处流程中所有成员的终极目标。无论一个成员或者团队角色是什么，他们都必须力图对这个系统进行深入的理解。这种思维方式对质量会有直接的影响，因为缺陷永远不会被放到"下游中"，这样做的话将会导致瓶颈的产生。
3. 确保整个工作流程不会被瓶颈堵塞住还不够。一个高产的组织应该时常考虑该如何提升整个工作流程。
4. DevOps原则不关心你身处哪个团队，你是否是系统架构师，DBA，QA，或者是网络管理员。相同的规则覆盖所有的成员，每个成员都应该遵循两个简单的原则：

*** 保持系统运作流程不可中断***
*** 随时提升和优化工作流程***

车道2 – 换挡加速

1. 不可中断的系统流程是定向的，且预期是从开发流向运维。在一个理想的世界中，这就意味着快速的开发出高质量的软件，部署，并为客户提供价值。
2. 如果单向交付是可行的话，瀑布模型模式就能胜任了。评估可交付产品和整个流程中的交流对确保质量是至关重要的。首个必须实现的"面向上游的交流通道是从Ops到Dev",下游的每一步反馈都必须紧跟着有一个上游的确定。

车道3 – 飞速前进

1. DevOps的第三个方式/快速车道包括每天分配时间来持续的进行试验，并将缺陷特意引入到运作系统上来以增加系统的抗击打能力。

DevOps – 清单

• 开发团队和运维团队之间没有障碍。两者皆是DevOps统一流程的一部分。
• 从一个团队流到另一个团队的工作的工作都能够得到高质量的验证。
• 工作没有堆积，所有的瓶颈都已经被处理好
• 开发团队没有占用运维团队的时间，因为部署和维护都是出于同一个时间盒里面的。
• 开发环境标准化，运维人员可以很容易将之扩展并进行部署
• 开发团队可以找到合适的方式交付新版本，且运维团队可以轻易的进行部署。
• 每个开发之间的通信线路都是很明确
• 所有的团队成员都有时间去为改善系统中来并得到处理。

总结

使用现代化的DevOps工具，如Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonQube、AWS等，并不代表你就在正确的应用DevOps的原则。DevOps是一种思维方式。我们所有人都是该系统流程的一部分。