Jennifer的故事

在2007年，雅虎的高管联系我说给我一个有一定开发和一定运维的岗位-高级服务端工程师来构建一个叫做Sherpa的多地分布式的可以替代现在的键值存储的数据。

作为雅虎的服务端工程师，我磨练了编程、运维和项目管理的技能。我和开发质量管理 的人一起开发Sherpa，并与数据中心、网络、安全、存储组协作工作。2009、当DevOps概念走进雅虎，我不相信它有什么价值，因为我认为自己已经是一个DevOps！

2011年夏天，Jeff Park接管了我的团队。他帮助团队成长，使我们在美国和印度的服务工程中拥有更多的人。这是不够的。杰夫担心我是一个不停地工作、几乎单枪匹马地维持服务稳定的员工。他也对这项业务感到担忧，并希望通过额外的人员支持，使整套流程变得更弹性化。12月，他告诉我要好好休假，不要看邮件或打电话，与工作断开联系。

我告诉他我觉得有些事情不太对，有些事情没能达到预期的效果。他告诉我如果我不休息的话他会炒我鱿鱼的。他向我保证一切都会好的。在度假之前，我写了一些简单的关于JavaScript，Perl脚本的定时任务，能够确保在假期看到服务每天的运行情况，相信它会提供足够的警告。

我度假回来看到一个回滚的系统。这么多年来我发现的许多小问题影响了整个系统，使调试变得更加困难。我觉得自己非常失败，尽管报警显示的数据定位到系统致命的原因。

Jeff告诉我说他知道在我离开的时候系统会有很大的危险，因为之前整个系统基本完全靠我维护，所以现在会有更多的问题发生。我只是忽略了系统内在的问题。

他认为有时短期的挫折是一件好事，如果你以后用它来作为一个教训，从长远来看正确的事情。如果事情往不好的方向发展，它将有助于优先考虑进一步分享、记录和分发我的知识和专长的重要性。最终，这将使组织和团队中更加稳定，并取得更好的结果。

结合Sherpa团队，从这件事中我们试图修复服务和了解发生了什么。我们按照不同的组织来定位不同的问题：故障处理、沟通、脚本工具、监控和故障清理。管理部门的关键人员保持随时待命以便做出决定。这些艰难的决定帮助我们减少服务停止的时间。

失败固然不好，但是可以指导我们该怎么改善。

— Bob Sutton, 斯坦福管理学教授

这次事件给我带来的一个关键的收获就是失败的价值。我们不能害怕失败，我们需要从失败中吸取教训。我们在会议中解决运维中出现的业务问题。我们继续改善在服务工程师团队中的跨小组的沟通问题。我们是需求和解决需求的人员更好的沟通，以便更好地理解系统中的薄弱环节。

我们已经花了10多年的时间建立起现在的运维文化—这种与世隔绝避免系统故障的现状，我该如何促使我做出改变呢？

我已经准备好往DevOps做改进。对我来说，DevOps的价值不是“开发者做这个运维做那个或者开发和运维”这么简单的概念，而是分享故事，解决跨业合作的方式问题，加强交流。以更开放的方式协作处理问题，一个新的支持系统正在出现，它加强了工作的可持续性，培养人与人之间的关系。

在和Katherine一起写书的过程中，加强了我对DevOps的认识。能够分享来自世界各地的工作策略和技术，以帮助改善和创造可持续的工作实践是一个令人难以置信的旅程。这本书有结束但是DevOps旅途并没有结束。

我们每天都基于我们不同的视角获得如此多的经验。无论你是在事业的开始，在文化转型中，或是要改变角色和责任，你的经历都能分享并且影响他人。我期待听到你们的故事，让我们一起在这个社区成长，共同学习我们的失败和成功的经历。