DevOps的“七大罪”及其解决方案相反，意识到错误是解决错误的重要起点。虽然我们可以通过多种方式正确实施DevOps，但也有可能出现失误。从缺少事件管理工具到忽略关键警报再到将DevOps作为职位名称，一切都可能毁掉您的DevOps工作。1.将DevOps视为一个标题，而不是一种哲学用许多成功的高管的话来说，“如果你把‘DevOps’放在你的标题中，那就错了。”DevOps是一种理论，而不是一个名称。简单地引入相关职位，并不能帮助企业实现DevOps。正如Bitilancer的MattJuszczak所写：拥有像DevOps工程师、DevOps系统管理员或DevOps测试员这样的职位本身就是对DevOps的根本误解。这种误解导致许多项目和计划的失败，损害团队和业务，并误导业务方向和招聘人员。相反，DevOps应该被视为一种旨在简化软件开发和转换的支持方法。事实上，DevOps定义要求运营和开发工程师参与整个服务周期，包括设计、开发过程和生产支持。2.未能被员工和CIO完全接受DevOps成功的本质在于改变对软件及其业务重要性的认知。DevOps是企业运营方式的根本转变，而不是技术变革。具体来说，DevOps经常使用新的工具和实践来改变技术满足业务战略的方式。但对于整个企业来说，要从DevOps中受益，高层的支持是必不可少的。这意味着我们需要一位熟悉DevOps的CIO来支持和指导相关工作。3、不注重量化指标彼得·德鲁克说：“如果不能量化，就无法改进。”量化指标是DevOps生命周期的第一步，应该贯穿于每一步。如果不衡量版本号的变化、平均修复时间或故障率，我们就无法知道我们获得了什么好处，甚至不知道我们在做什么。AppDynamics写道：正确的量化指标是确保DevOps转型成功的关键。但是，不应简单地受限于技术指标。除了平均修复时间（简称MTTR）或平均无故障时间（简称MTBF）外，还应该关注过程和人员指标。月活跃用户或日活跃用户等可以帮助我们很好地了解当前的实施效果。4.将DevOps视为一场军备竞赛DevOps不应被简单地视为由工具的数量决定。在DevOps世界中，与发布、配置管理、编排、监控、虚拟化和容器化相关的工具层出不穷。虽然与时俱进是可以的，但我们还是应该有针对性地关注它真正实现自身改进目标的能力。真正的DevOps解决方案应该对开发人员、运维人员和安全人员具有吸引力。正如一位工程师所写，如果日常生活将被新的“DevOps”工具打乱，那么确保相关团队尽早采用至关重要。否则，其他团队将难以接受该解决方案，永远无法真正发挥其全部潜力。DevOps的核心是打破壁垒和壁垒，确保员工能够更快地完成工作。这意味着管理层需要全力投入，而不仅仅是购买更多工具。5.无法接受的失败即使企业已经开始正确实施自动化计划并获得管理层的支持，DevOps团队也没有必要接受失败的结果。例如，Netflix会主动诱发故障条件，以确保为服务器停机或代码错误做好准备。在理论层面上，管理层需要认识到失败是构建和发布代码实践中不可避免的因素。失败后，我们应该总结经验，建设性地发现问题，而不是一味地相互指责。理想情况下，一组失败的发布应该：“基于错误进行新一轮的测试，确保以后不再出现。只有这样做，企业才能真正接受DevOps的核心理论。”6.仍然强调开发和运维之间的区别有效的DevOps“强调整体系统性能，而不是特定工作或部门的孤立性能。”正如许多相关文章中提到的那样，开发人员不能闭门造车编写代码并期望它能够按照预期顺利运行。相反，开发人员和运营商应该共同努力。这通常意味着开发和运营双方应该始终保持沟通。如果开发人员对他们的代码产生的问题负责，他们显然会更认真地编写和测试他们的代码。同样，如果运维人员感受到了开发人员所面临的压力，他们也会保持与之一致的工作态度。7.没有使用关键的告警工具如果你没有使用关键的告警工具来通知工程师严重的事件，那么DevOps系统将会遇到更多的问题。未能将关键警报工具纳入DevOps团队的核心理念将导致：团队专注于量化指标的能力将大打折扣。例如，如果我们不知道事故何时发生，如何减少平均维修时间？有效的取证将更加困难。关键警报工具允许团队查看警报消息中提供的相关错误描述。开发和运营之间的差距将继续存在。通过将“on-call”任务分配给两个团队，两个团队都可以随时查看警报内容。清楚地了解警报后，他们会更有效地移情。关键警报工具对于减少停机时间、保持客户满意度和快速解决问题至关重要。事实上，忽视这些要点，继续使用根本达不到告警目的的工具，应该被称为渎职。小结看完这篇文章，或许很多朋友都觉得戳中了痛处。不过不用太担心，DevOps这“七宗罪”的存在，并不意味着企业就没有希望了。相反，意识到错误是解决错误的重要起点。另外，这里提个建议，大家不要盲目贪多。一次处理一个犯罪行为往往更安全、更有效。原标题：DevOps的7个致命罪恶以及如何避免它们原作者：OrleeBerlove
