导读web
本系列文章分为三个部分，咱们将回顾过去的三年，总结稳定Marathon方面的经验，与你们分享。编程
首先，在本篇文章我会先从咱们的团队文化谈起，接着会谈到咱们的代码文化和设计。最后，我将描述咱们的测试pipeline，以及回顾和展望。微信
这是咱们过去三年在如何稳定Marathon方面总结的经验。Marathon是DC/OS中的中央工做负载调度程序。大多数时候，当您在DC/OS上启动应用程序或服务时，在Apache Mesos上启动它的是Marathon。Mesos管理计算和存储资源，Marathon协调工做负载。咱们有时把它称为"DC/OS的init.d"。做为DC/OS不可或缺的一部分，咱们必须确保它能持续运行。请注意，我没有提到"宕机"。您将在后续的系列文章中了解缘由。 网络
在咱们开始以前，我要感谢团队成员勤勉工做，感谢咱们的客户和客户支持工程师们在Marathon没有按预期运行时所表现出的耐心。尽管咱们已尽力避免，但在生产中仍然出现了bug。与客户的电话会议极大的促进了Marathon的稳定性。然而，在本文中，我想探讨如何避免出现这些状况以及如何使它们处理起来更容易。app
关于Marathon稳定的经验，不得不从咱们的团队文化谈起，接着的文章会谈到咱们的代码文化和设计。第三部分描述的是咱们的测试pipeline。最后，我将以回顾和展望做为结束。能够随意跳过关于团队和代码文化的部分。可是，我坚信它们对咱们的技术产生了影响。分布式
第一部分：团队文化工具
在过去的几年中，咱们创建了必定的团队文化。我想分享四个方面，我认为这些方面不只影响了咱们的代码质量，并且帮助咱们成为卓越的团队。学习
作最完美的设想测试
咱们始终设想每一个人在工做中都怀着最好的意图。这种思惟方式避免了没必要要的冲突，并有助于咱们专一于手头的技术问题。想一想看。你真的认为有人故意写错代码吗，仍是他们或者你故意遗漏了某些信息？咱们经常发现代码部分或做出变动会在团队中引发争议，由于做者、审查员或二者对于咱们想要解决的问题都缺少足够的信息和理解。认可每一个人都怀着最好的意图，即想要使产品更好，会打开许多大门。这个想法将我引向了下一个原则。spa
尊重先前的成果
编写Marathon原始代码时，个人团队成员都不在身边。咱们经常会由于原始代码出错和糟糕而想放弃代码。对咱们来讲，深刻研究它并尝试理解为何要以这种方式编写要困可贵多。前一种态度会致使“非我所创综合症”以及没必要要的重写。所以，咱们将重点放在后一种方法上并深刻钻研。这项艰苦的工做一般会带来回报，使咱们得到涵盖原始代码试图解决的边缘状况的新洞察及代码改进。
加倍投入，以期成功
前两个原则让咱们进一步了解Marathon。那咱们如何实现咱们的新洞察？——对它们加倍投入。咱们很早就意思到，发现专一于上次生产失败或错过最后期限不只使人沮丧，并且也无助于咱们向前迈进*。正如团队成员蒂姆（Tim）所说：“这就像去购物时列出了不要购买的东西的清单”。咱们一点也不明智。因此咱们决定把精力集中在有效的东西上，并加倍投入。这个工具帮咱们找到了一个bug？让咱们改进它并教导支持团队使用它。这个代码更改解决了竞争条件？让咱们花点时间在其余部分也作些更改。
结对编程和两个评审员
咱们正在学习，而且咱们加倍投入，以期成功，可是这在平常工做中会是什么样子呢？咱们很快发现，创建更多的流程带来的每每是更大的开销，因而咱们鼓励同事们进行结对编程，并强制使用两个代码审查员。这是咱们的强制选项，以增长应用咱们所学知识的机会。若是两个工程师结对解决一个问题，那么他们已经对代码更改有了大体的了解。审查不过是简单的签核。然而，当添加第三方时，他们就会提出问题，例如《童子军规则》*，他们会指出上周刚刚引入的帮助课程或团队赞成的模式。我真的很喜欢扮演一个不知情的审查员，并提出一些问题来阻止拉取请求，这让个人团队成员很恼火。然而，我坚信个人“为何”和“如何”有助于改进代码库。
*这一原则与Rework中的“Learning from mistakes is overrated（从错误中学习）”相似。
*可在马丁（Martin）的著做《Clean Code》中找到。
点击“阅读原文”体验由稳定的Marathon造就稳定的Mesosphere DC/OS
往期精彩文章
关于D2iQ
点击“阅读原文”，体验Mesosphere DC/OS
本文分享自微信公众号 - D2iQ（d2iq_apac）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。