这又是一番偏执的胡言乱语。做DevOps两年以来，见过好的实践，也见过糟糕的实践。每一个对DevOps实践都有不同的认识，在这篇博客，我只是聊聊自己的观点，如有不对敬请指正。
大致而言，我会遵循三个原则：
- 零手动操作。
- 干净：童子军军规。
- 简单：奥卡姆剃刀。
零手动操作
什么是手动操作？任何没有被代码化（as code）的资源或者操作都可以被认为是手动操作。
常见的手动操作：
- 基础设施没有代码化，存在资源是没有被代码管理，或者部分操作没有被管理。
- 应用部署流程需要手动干预。
- 应用配置需要手动指定等。
真的要手动操作？
当你需要做任何手动操作之前，先问自己一系列问题：
- 该操作是否以及被代码化（as code），如果是，那就执行代码。不要把自己的代码遗落在角落里。如果没有，继续下一个问题。
- 该操作是否紧急？如果紧急，那么可以临时手动操作，但是需要多个人一起以及严格的流程。之后，需要将该操作代码化。如果你不想代码化，那么看看下面一系列问题？
- 该操作在后续是否还有发生的机率？如果有，就需要代码化。如果你依然不愿意，继续下一个问题。
- 如何确保在下一次执行（可能间隔一周，也可能是间隔一个月）的时候完全重复当前操作？任何手动操作都是不可被追溯的，不可完全被重复的。如果确保不了，那就需要代码化。如果能确保，那你就是神，我只能表示膜拜。
- 我们有完备的文档，还需要代码化吗？代码比文档可靠，优雅的代码可读性远高于文档。
避免手动操作的实践
- 基础设施即代码（IaC，Infrastructure as code）
- CI/CD
- 自动化脚本（Automation script）
- GitOps
干净：童子军军规
The Boy Scout Rule: Always leave the campground cleaner than you found it.
干净，可以从两方面说，代码整洁和环境干净。童子军军规：让营地比你来时更干净。这是一条非常适用的规则。
代码整洁
代码整洁中的“代码”不仅仅指业务代码，还应当包含测试代码，基础设施代码等一切代码。我见过一些业务代码很整洁，非业务代码很糟糕的项目，为什么会这样呢？我大胆地猜测一下，团队没有把基础设施代码当成代码，而是在战略上忽视了它。
所有的代码享有平等的地位。无论是否是业务代码，在应用的生命周期中，我们都需要去维护。
关于这部分的内容，强烈推荐学习一下《代码整洁之道》和《重构》。
环境干净
在开发阶段，保持开发环境的干净。
在CI/CD 环境中，保持构建、测试、部署环境干净。通常而言，一个CI/CD 的Agent会被不止一个应用使用，因此保持环境的干净就显得尤为重要。
在生产环境中，保持运行环境干净。
实践
- TDD
- Simple Design
- 容器化
- Code Diff
简单：奥卡姆剃刀原理
Entities should not be multiplied unnecessarily
在写这篇的博客的时候，我也一直在纠结是不是要把干净和简单合并在一起写。在提到干净的时候，它和脏是对立的，往往是指代码是否整洁。而简单和复杂是相对应的，通常是和业务，架构，技术栈等相关的。
业务复杂与否是来自于功能需求，这一块儿没有深入研究过，暂且不谈。
架构和技术栈的复杂度来自于非功能性需求。一个项目总会有人员的变动，在人员变动的过程中，复杂的东西在传递的过程中很容易失真。在引入一项新的技术或者语言时，需要仔细考虑是否真的需要，如果不是必须的就不要引入。简而言之，遵循奥卡姆剃刀原理：如无必要，勿增实体(Entities should not be multiplied unnecessarily)。