54、实现DevOps：从理念到实践

实现DevOps：从理念到实践

1. DevOps的核心：人员协作而非技术

很多人将DevOps视为一种软件交付方式，但实际上它更定义了人们的协作方式。即便使用大型机、COBOL和JCL，也能实现DevOps，并非一定要依赖CI/CD。DevOps的真正潜力在于明确人员的交互方式、优化工作流程以及促进协作，而非单纯依赖技术。技术固然酷炫，但更重要的是发现流程中的漏洞，例如交接环节的存在原因及能否消除，如何处理安全审计和变更控制委员会的要求，以及这些对工作流的成本影响。

改变人们的工作思维模式比引入工具困难得多。以基础设施团队采用源代码控制为例，这可能需要多年时间。经验丰富的工程师习惯通过SSH登录服务器并输入命令，让他们转变为每次变更都检出和部署基础设施代码，会觉得速度变慢。改变这种思维模式比更换工具要困难得多。

2. 测试：持续交付的关键瓶颈

测试是持续交付中最难的部分，但往往被大家忽视。虽然90%的代码覆盖率很棒，但这并不意味着代码能实现预期功能，也不能保证在正确的位置调用代码。

单元测试虽能作为规范并证明代码按设计运行，但有时即便运行了大量单元测试，生产环境中的构建仍可能失败。因此，单元测试仅作为一种初步测试，为开发人员提供快速反馈。工程师应更多地关注系统和集成层面的测试，确保真正为客户解决问题。

3. 基础设施即代码：摒弃“黄金镜像”的神话

稳定性不应是唯一目标，更应关注当前状态、期望状态以及所需的特性。大多数情况下，静态的“黄金镜像”并非理想目标，我们需要的是符合标准且及时更新的镜像，包含最新的用户账户和安全补丁。

Docker和Kubernetes虽被视为神奇的技术，但实际使用中可能会让开发者变得懒惰，认为只需将代码放入容器就能实现可移植性和安全性。未来几年，可能会出现基于镜像漏洞的重大安全问题。不过，容器化的好处是能提供一套文档完善的API，使应用具有一些共同特性，便于管理。

以下是一个简单的对比表格，展示“黄金镜像”与及时更新镜像的差异：
| 类型 | 特点 | 优势 | 劣势 |
| ---- | ---- | ---- | ---- |
| 黄金镜像 | 静态、长期不变 | 初始配置简单 | 缺乏更新，存在安全风险 |
| 及时更新镜像 | 动态、符合最新标准 | 安全性高，功能最新 | 维护成本高 |

4. 微服务：利弊共存

微服务目前非常流行，在大规模开发中几乎是必需的。通过将交互点转化为API，能让大量工程师共同协作开发一个大型项目。在小规模开发中，微服务也能带来好处，例如创业公司可以快速迭代，在不改变前端的情况下修改支付流程。

然而，管理多个在线服务比管理少数服务更复杂，人们往往低估了分布式计算的复杂性。预计未来会有大公司放弃微服务，因为投资回报率不理想。就像早期的可用性集群，最初使用时可能会降低可用性。如果擅长使用微服务，它会带来巨大优势；反之，则会成为无尽的麻烦。

下面是微服务使用的流程图：

graph LR
    A[需求分析] --> B[设计微服务架构]
    B --> C[开发微服务]
    C --> D[测试微服务]
    D --> E[部署微服务]
    E --> F[监控与维护]
    F --> G{是否需要优化?}
    G -- 是 --> B
    G -- 否 --> H[持续运行]

5. 监控：从数据到业务价值

监控常被忽视，但它本质上是在生产环境中的测试。监控时不应只关注普通指标，而应从用户角度出发，确保应用正常运行，并将相关信息以有意义的方式呈现给公司的关键人员。

将监控数据转化为业务价值很重要，例如将问题转化为成本，这样能让非技术人员更好地理解问题的严重性，便于进行决策和讨论。开发人员应更多地考虑所构建系统的长期维护成本，因为随着时间推移，运营和维护成本会远超开发成本。

6. 文化冲突与变更控制委员会：打破官僚主义

政治和组织问题是最难解决的问题，官僚主义和风险规避使得人们绕过规则而非遵循规则。例如，为避免变更申请被审批，直接在后台进行工作；为不影响高管的可用性仪表盘，在服务停机时展示静态图片。

变更控制委员会（CAB）会议常被诟病，虽然在某些情况下能发现并行变更中的依赖问题，但这种情况并不常见。很多时候，人们通过日常沟通就能解决问题。可以考虑将变更控制会议转移到Slack等沟通渠道，以提高效率。

7. 招聘适配的人才

招聘合适的人才至关重要，应优先寻找具有学习导向思维的人，他们应展现出学习和适应的意愿，以及积极的态度。面试时，可采用面试小组的方式，因为一个人很难全面评估候选人是否适合团队。

面试中可以通过以下方式了解候选人：
- 询问他们最酷的项目经历，了解其热情和对项目的理解。
- 探讨分布式计算的优缺点及应对策略，考察其技术知识。
- 询问对理想经理和糟糕经理的看法，了解其对团队文化的期望。
- 了解职业目标和对反馈的期望，评估其自我规划和成长意愿。

此外，还可以提出一些具有挑战性的问题，如“Nagios和Jenkins的根本区别是什么”，以挑战候选人的固有观念并引发深入讨论。

8. 总结与建议

为实现高效的DevOps实践，可参考以下建议：
- 明确测试或构建管理系统可能是关键瓶颈，重视并优化这些环节。
- 强制进行良好的单元测试，并为团队提供培训和优质框架。
- 通过Bug Bash等方式将质量测试游戏化，提高团队参与度。
- 持续为业务提供新价值，避免孤立地追求质量。
- 避免复杂的分支结构，以免影响交付速度。
- 使用仪表盘和记分卡防止团队自满。
- 不断淘汰不稳定或低效的测试用例。

总之，实现DevOps需要关注人员协作、测试、基础设施管理、微服务、监控、文化等多个方面，并招聘适配的人才。只有全面考虑这些因素，才能提高团队的生产力和软件质量，实现业务目标。

实现DevOps：从理念到实践

9. 测试与构建管理：工程系统的瓶颈

在工程系统中，测试或构建管理系统往往是瓶颈所在。人们通常认为测试缺乏吸引力且投资回报率低，因为要处理大量遗留代码并进行改造是一项艰巨的任务。然而，对于很多团队来说，这是实现高效开发和交付的关键因素。

以某团队为例，他们在实践中发现，尽管团队的功能开发速度较快，但CI/CD管道却因质量标准难以通过而受阻。经过分析，他们确定问题出在测试环节。于是，他们决定加大对测试的投入，包括优化测试框架、增加自动化测试用例等。通过这些努力，团队最终提高了交付速度，实现了业务目标。

以下是解决测试与构建管理瓶颈的操作步骤：
1. 识别瓶颈 ：通过监控和分析开发流程，确定测试或构建管理系统是否是瓶颈。
2. 评估现状 ：了解当前测试和构建管理的流程、工具和资源，找出存在的问题。
3. 制定计划 ：根据评估结果，制定优化测试和构建管理的计划，包括目标、策略和具体措施。
4. 实施改进 ：按照计划逐步实施改进措施，如更新测试框架、增加自动化测试、优化构建流程等。
5. 监控和评估 ：持续监控改进效果，根据反馈及时调整计划，确保达到预期目标。

10. 微软的向左移动运动

微软在Visual Studio的开发过程中，大约在2010年开始向敏捷开发转型。三年后，他们发现尽管功能推出速度较快，但CI/CD管道出现了问题，难以通过质量标准。于是，在2014年左右，他们开始进行调整。

以往，每个团队都有独立的开发、测试和项目管理小组，大家逐渐意识到这种分离的模式不利于构建服务，这些不同的专业领域实际上是一个整体。因此，他们开始打破部门壁垒，促进各小组之间的协作和沟通。

以下是微软向左移动运动的流程图：

graph LR
    A[开始敏捷转型] --> B[发现CI/CD问题]
    B --> C[认识到部门分离问题]
    C --> D[打破部门壁垒]
    D --> E[促进协作与沟通]
    E --> F[优化开发流程]
    F --> G[提高交付质量]

11. 持续关注业务价值

作为运维人员，应关注业务成果，而不仅仅是技术本身。如果了解公司的核心业务，如生产拖拉机、汽车或软件等，并将自己的工作与这些业务功能联系起来，会更有动力和成就感。

以下是一个简单的表格，展示关注业务价值的好处：
| 关注点 | 好处 |
| ---- | ---- |
| 业务价值 | 提高工作动力和成就感，更好地满足业务需求 |
| 技术本身 | 可能导致工作与业务脱节，缺乏长期价值 |

12. 总结与展望

实现DevOps是一个综合性的过程，涉及人员协作、测试、基础设施管理、微服务、监控、文化等多个方面。在实践中，我们需要关注以下几点：
- 人员协作 ：强调人员协作是DevOps的核心，通过优化人员的交互方式和工作流程，提高团队的整体效率。
- 测试优化 ：重视测试环节，将其作为持续交付的关键瓶颈进行优化，确保代码质量和系统稳定性。
- 基础设施管理 ：摒弃“黄金镜像”的神话，采用及时更新的镜像，提高系统的安全性和功能完整性。
- 微服务应用 ：合理应用微服务，充分发挥其优势，同时注意避免分布式计算带来的复杂性。
- 监控与业务价值转化 ：加强监控，将监控数据转化为业务价值，为决策提供有力支持。
- 文化变革 ：打破官僚主义和部门壁垒，促进团队之间的协作和沟通，营造积极的工作文化。
- 人才招聘 ：招聘具有学习导向思维和积极态度的人才，确保团队的适应性和创新能力。

未来，随着技术的不断发展和业务需求的变化，DevOps实践也将不断演进。我们需要持续关注行业动态，不断优化和改进自己的实践方法，以适应新的挑战和机遇。通过不断努力，我们可以实现更高效的软件开发和交付，为企业创造更大的价值。