21CTO社区导读：无论你是刚刚开始从事开发者的职业生涯，还是有可靠的项目组合，也正在考虑转换为DevOps，本文是表达我对DevOps想要如何在这个残酷世界中生存的看法。
我最近正大读凤凰计划这本书，通过前面的章节，我已经认识到我在职业生涯中遇到的很多模式。虽然我不期待成为DevOps的专业人士，但我认识到在组织内部有一个DevOps团队的重要性，这样开发人员就不用处理服务器的部署，配置管理或变更管理等操作了。
第一个目标
通过所有业务，开发和运营公司部门的自动化，系统监控和信息共享文化消除浪费
是的，这是一个非常重要的目标。关键我可能会说。您需要确保IT运营和开发部门协同工作，而不是彼此分开。它并不像理论上那样容易。
关于消除浪费的这句话来自精益六西格玛，这是一种依靠协作团队努力通过系统地消除浪费和减少变化来提高绩效的方法。
你必须与上层管理人员或下层管理人员进行沟通，以确定并消除路径中的所有干扰和浪费。
稳定性是你的首要考虑因素，你必须保持高标准并坚持自己的标准。否则，你将在服务器机房度过一个又一个的夜晚。
你是绑定业务，开发和运营内部部门的粘合剂。如果这种胶水变薄，那么业务就会被搞砸。
这让我们接下来的事实来观察。
当灾难发生时确保问题被覆盖
不，我的意思不是那样......
不是耸人听闻，灾难可能迟早会发生。当每个人都喝醉了，或被解雇的员工触发系统逻辑炸弹，有缺陷的软件或外部因素可能导致问题时，它能否会在新的一年能投入到生产环境中？
你要意识到的一件重要事情是：
复杂的系统意味着失败
复杂系统是什么意思？平均包含超过7个节点或组件的任何东西，它们作为整个系统的一部分相互交互。
为什么？这是因为我们人类可以同时管理的物品，任务或交互的完美数量。
什么是节点或组件？它是具有逻辑边界的任何东西，例如UI Web应用程序，后端服务，数据库服务器，操作系统等。如您所想，即使简单的3层系统也很复杂，它们将一定失败。
所以为了让你能够满足自己的要求：
你需要优化睡眠......
这意味着你需要确保一切都是自动化。
以下是我认为折自动化：
运行测试：所有测试用例都是单元，系统应该是管道的一部分，确保在测试失败的情况下不会发生任何中断。
收集度量标准：所有度量标准，回溯，监视数据应以最非阻塞的方式运行，而不是消耗资源。将日志收集到安全的地方。
运行报告和警报
自我修复：在服务器上运行的软件能够进行必要的调整，以便在发生故障时将自身恢复到正常运行状态。
备份
这只有最低的要求......
让我们继续下一个观察。
记录一切
你需要记录一切。
我的意思是这样的：
自动化：一切都要回到自动化。
文档的确很难维护。您需要有一个自动脚本，为每个流程保留实时wiki，无需人工干预即可开放API，配置，需求，校验规则等。
持续：每次发生变化时都应该调用文档生成，并且需要与当前环境保持一致。
可跟踪：文档应具有可跟踪的元数据。谁更新，何时更新和什么原因。
详细说明：文档应该尽可能详细。仅仅使用“使用最新的OS补丁更新了10个终端”这样的内容是不够的。你需要更具体地说明补丁版本信息应用补丁的步骤，观察到的效果等。
我们进入另一个维度的观察。
需求控制变更
开发者是最好的朋友，他们需要确保新代码行无缝集成到组织中。运维者需要更紧密地协同工作并自动化部署过程。
这将导致频繁发布
这实际上并不是问题，因为它证明了一切都可以作为运行良好的机器运行。你需要始终掌握所有业务需求，以及当前开发状态，以便按时计划发布。
当然，这将带来很好的开发经验，但如果爱你的工作，你就可以做任何事！
小结
至此，我们已经了解了DevOps角色时的预期。请记住，这只是开发人员的观点。当你处理自己的角色时，你会发现更多需要遵循的最佳实践。