我在 Twitter 当工程师学到的三件事 _Twitter

我离开 Amazon 已经快一年了，来到 Twitter 工作以后，我学到了很多东西，也意识到了很多事情。

1. 服务及健康软件工程并不局限于为客户构建新的功能，还要确保现有服务的健康及功能。服务在性能方面上不应该出现倒退现象。这对于维护客户的信任非常重要。如果你现有的服务不能提供相同的 SLA（Service-level agreement，服务级别协议），那么客户为什么还要用你的服务呢？
维护服务的方法有很多种：

随叫随到
监控
自动化系统
操作规范化

随叫随到（OnCall）是维护服务健康的最大因素。如果服务发生实时停机事故，随叫随到可以尽快缓解这一情况。否则，事件拖得越久，后果就会越严重。例如，最终用户的影响可能是无法吸引新用户，从而导致收入损失。最重要的是永远不要危害产品，以免用户停止使用产品。
当内部客户的服务或工作表现不佳时，他们可以通过通信平台（如 Slack）发起呼叫请求。大多数情况下，随叫随到是由监控系统传呼的。监控系统允许工程师通过关键指标（如成功率、读写延迟、流量、内存空间等）来跟踪服务的性能。因此，随叫随到可以全面了解他们的服务中正在发生的事情，从而可以更快地调试问题。
在这些监控系统中，可以为关键指标设置一个阈值，当超过这个阈值时，随叫随到将会被传呼。然而，这些阈值的设置，却有可能是一把双刃剑。如果阈值设置不当的话（即设置过低或过高），随叫随到可能会被大量传呼所淹没。阈值需要设置为只有在服务遇到问题时才会突破的值。同样，工程师也不应过于热心，为每个指标设置一个阈值。你需要警惕的是那些可以采取行动的指标，这些指标如果不能迅速解决的话，可能会产生毁灭性的影响。
减轻随叫随到的负担并改善服务健康状况的可行解决方案是自动化。如果某个问题不断地重复出现，并且无需人工干预即可解决，那么就可以采用自动化。自动化系统可能会产生很大的影响，但如果不实施保障措施，可能会产生不良后果。例如，在重新启动有状态服务的实例时，不要同时重新启动所有实例，这一点很重要。
自动化系统甚至可以与监控系统集成。只要达到特定指标的阈值，监控系统就可以触发自动化。
为了防止人工操作造成问题和事故，必须保持高度的操作规范化。解决这个问题的一种方法是制定一个文档完整的运行手册，其中列出了每个手动操作的详细步骤。最重要的是，另一个团队成员可以验证操作员的操作过程，特别是在已知操作会导致问题的情况下。
50% 的软件工程都是维护服务的健康。这不是工作中微不足道的一部分。要知道，软件工程并不仅仅是编写代码。
2. 代码的可持续性要确保任何推入的代码都能灵活地应对变化是很重要的，当业务需求发生变化时，这一点尤为重要。
使用 DRY 原则
DRY 代表 “Don’t Repeat Yourself” 。（不要重复自己写的代码）。同一段代码不应在许多场合重复。如果你看到这种情况，那么可能需要对其进行抽象以避免出现冗余。这样，如果你需要修改它的逻辑，只需在一个地方修改它即可。
始终测试
始终为你编写的任何函数编写测试用例。引入的任何新特性都不能破坏系统的现有状态，这一点很重要。测试可能是乏味的，但它将会带来巨大的回报。
架构优先
如果在编写代码时不考虑架构，这将会产生滚雪球效应。在编写代码时，要想想其他服务将如何与它进行交互，将来更新它有多容易，以及如何测试它。编写代码的方式应该是，如果需要交换一种逻辑，那么放入一个新的逻辑是很容易的。
使用常量
永远不要硬编码。相反，要使用常量。这样，如果将来需要更新值，只需修改一次，而不是多次。
3. 采取主动工程师永远不应该停滞不前。他们应该努力成为团队的领导者。为了在你的团队中扩大你的影响力，你必须采取主动，并愿意接受你不喜欢的新任务。优秀工程师的标志就是他或她能够在最少的帮助下解决新的挑战。我已经开始更多地参与自己并不熟悉的服务的代码评审。我敦促自己对关于边缘案例或弱点的技术设计文档进行更多的评论。我甚至和我的经理谈过，让我参与一些能够帮助我加强自身弱点的项目。
强迫自己进入一个新领域，并不是你唯一应该做的事情。你还需要提前考虑团队将面临哪些挑战，以及如何应对这些挑战。在它成为一个真正的问题之前，一定要提前考虑并及早解决。积极主动是我目前正在学习的一项技能。希望通过对这些技能和目标的努力，我能够在下一阶段取得更好的成绩。