是时候让DevOps变得个性化了

多年来，随着我们的基础架构迁移到云中，它变得更加抽象和可自我纠正。在这段时间里，很难忘记的是，当出现严重错误时，仍然是系统另一端的人正在醒来修复它。

科技界“快速行动，打破常规”的口号已经传播到许多其他依靠IT基础架构为其产品和服务提供服务的行业和部门，但是这种工作方式可能会破坏他们最重要的资产：员工的健康和士气。

规模带来了复杂性，而复杂性带来了不可预测性：今天的待命IT工作者不知道什么时候可以在早上四点醒来解决事件，这是一个问题。错误和延误造成数百万美元的损失，并且企业需要尽快解决严重的故障是可以理解的，那么我们如何才能继续前进并为工程师创造一个更具吸引力的健康环境？

 善于扩展DevOps

快速补丁发布和连续交付模型的期望给寻求改进其产品的企业带来了压力。可以理解，许多公司正在寻求DevOps的实践，以减轻这种负担并修改其团队结构，以便开发和运营能够以更高效，更敏捷的方式协同工作。

但是，该方法可以进一步扩展。尽管IT经理现在已经习惯于研究团队如何合作，但是从总体上来说，该行业很少善于考虑个人，他/她与工作的关系以及“永远在线”文化可能产生的不利影响。在IT工作者身上。

如果您在凌晨3点醒来进行紧急修复，那么第二天您的工作效率就不会很高。这听起来似乎很明显，但令人惊讶的企业数量却没有考虑到这一点，考虑到一些研究表明睡眠中断比睡眠不足更令人震惊。系统管理员和值班人员应在白天或晚上的所有时间都可以使用，但他们不是“超级英雄”或“忍者”。这种期望及其造成的持续压力可能对员工的健康非常不利。

工作满意度低的工人很可能会提前离职：根据一些估计，更换员工的成本可能高达该员工年薪的21％，因此从健康和福祉的角度考虑员工的应对方式会严重影响业务。底线。最近，在GitLab的数据丢失事件中，我们还集中注意力缺乏注意力的灾难性后果。

我从经验中知道这一点：创办我自己的公司的头几年，我一直在待命。我们的团队只有几个人，所以我发现晚上经常因为与朋友交往而被叫走。这促使我看到，作为一家公司，如何在处理IT警报时可以使通话变得更加轻松，还可以了解整个行业如何实现相同的目标。

那该怎么办呢？

对于基础架构监视公司的创始人来说，谈论这一点似乎很奇怪：毕竟，服务器监视包括发送警报和唤醒人们。我们意识到，我们有责任倡导IT团队采用更可持续的工作实践，因此我们将这些实践称为HumanOps。

HumanOps有几种核心原则，但是要记住的最重要的原则是人类健康会影响企业健康。正如理查德·布兰森（Richard Branson）喜欢说的那样：“如果您照顾好员工，您的客户和底线也将得到回报”。如果企业优先考虑员工的福利，那么系统性能，员工保留率和生产率都将得到改善。

这些是理论上的好主意，但是我们如何制定实用的政策来实施它们呢？开发人员可以从与他们的经理一起开始，重新评估问题的升级方式，问题的升级人员以及监督呼叫工作量的人员。建立内部协议，以确保在您打电话给某人之前，所有替代方法都已用尽，并理想地确保重要知识不会仅存在于负责解决问题的一两个人中。

实施诸如无罪的验尸之类的政策，以及提高人们对睡眠不足影响的普遍认识，对于将同情带回到电话上的IT工作大有帮助。您甚至可以要求您的经理加入呼叫轮换，亲身体验中断-许多公司都采用这种方法，因为没有什么比不断地提醒他们提高修复优先级的方法了！

软件制造商有责任确保其产品按预期工作，这应包括确保员工具备足够的能力以健康和可持续的方式工作。诸如工时中断成本，每位员工在呼叫上花费的时间以及非工作时间触发的警报数之类的指标可以帮助管理人员了解其特定公司中优先级最高的问题领域的概况。

DevOps以及这些实践可以为企业带来很多活力和热情，但重要的是不要仅专注于技术实践而忘记DevOps的人为因素。现在是时候了，我们认识到工程师是压力很大，需要停机的人，并且有满足这些需求的强大的商业和社会原因。俗话说，最重要的资产每天晚上回家，所以让他们睡个觉。