DevOps简记录

敏捷宣言基于以下十二条原则：

我们的首要任务是通过尽早地、持续地交付可评价的软件来使客户满意。

乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从而为客户赢得竞争优势。

频繁交付可使用的软件，交付间隔越短越好，可以从几个星期到几个月。

在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持，并且信任他们能够把工作完成好。

与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是，面对面的交谈。

可使用的软件是进度的主要衡量指标。

敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。

为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。

简洁——最大化不必要工作量的艺术——是至关重要的。

最好的架构、需求和设计都源自自我组织的团队。

团队应该定期反思如何能变得更有战斗力，然后相应地转变并调整其行为。

\精益有以下7个原则：

杜绝浪费

内建质量

创建知识(放大学习)

延迟决策(尽量延迟决定)

快速交付

尊重人员(团队授权)

全局优化

车道1 – 获取速度
要采纳DevOps的原则，理解整个运作系统的重要性并对工作事项进行合适的优先级排序是组织首先要学的事情。在整个价值流中不能允许任何人产生瓶颈并降低整个工作流程。
每个成员都应该遵循两个简单的原则：

保持系统运作流程不可中断

随时提升和优化工作流程
车道2 – 换挡加速
不可中断的系统流程是定向的，且预期是从开发流向运维。在一个理想的世界中，这就意味着快速的开发出高质量的软件，部署，并为客户提供价值。
车道3 – 飞速前进
DevOps这条快速车道并不适合意志脆弱的人。为了进入这条车道，你的组织必须要足够的成熟。这里充满了冒险和对失败教训的学习，不断的尝试，并认同屡败屡战和不断的实践是走向成功这条康庄大道的前提条件。在这里你应该会经常听到”套路“这个词，这是有原因的。不断的训练和重复所以能培养出大师，是因为其让复杂的动作常规化。

开发团队和运维团队之间没有障碍。两者皆是DevOps统一流程的一部分。

从一个团队流到另一个团队的工作都能够得到高质量的验证

工作没有堆积，所有的瓶颈都已经被处理好。

开发团队没有占用运维团队的时间，因为部署和维护都是处于同一个时间盒里面的。

开发团队不会在周五下午5点后把代码交付进行部署，剩下运维团队周末加班加点来给他们擦屁股

开发环境标准化，运维人员可以很容易將之扩展并进行部署

开发团队可以找到合适的方式交付新版本，且运维团队可以轻易的进行部署。

每个团队之间的通信线路都很明确

所有的团队成员都有时间去为改善系统进行试验和实践

常规性的引入(或者模拟)缺陷到系统中来并得到处理。每次学习到的经验都应该文档化下来并分享给相关人员。事故处理成为日常工作的一部分，且处理方式是已知的

现代化的DevOps工具，如Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS等