我離開 Amazon 已經快一年了，來到 Twitter 工作以后，我學到了很多東西，也意識到了很多事情。

1. 服務及健康

軟件工程并不局限于為客戶構建新的功能，還要確保現有服務的健康及功能。服務在性能方面上不應該出現倒退現象。這對于維護客戶的信任非常重要。如果你現有的服務不能提供相同的 SLA（Service-level agreement，服務級別協議），那么客戶為什么還要用你的服務呢？

維護服務的方法有很多種：

• 隨叫隨到
• 監控
• 自動化系統
• 操作規范化

隨叫隨到（OnCall）是維護服務健康的最大因素。如果服務發生實時停機事故，隨叫隨到可以盡快緩解這一情況。否則，事件拖得越久，后果就會越嚴重。例如，最終用戶的影響可能是無法吸引新用戶，從而導致收入損失。最重要的是永遠不要危害產品，以免用戶停止使用產品。

當內部客戶的服務或工作表現不佳時，他們可以通過通信平臺（如 Slack）發起呼叫請求。大多數情況下，隨叫隨到是由監控系統傳呼的。監控系統允許工程師通過關鍵指標（如成功率、讀寫延遲、流量、內存空間等）來跟蹤服務的性能。因此，隨叫隨到可以全面了解他們的服務中正在發生的事情，從而可以更快地調試問題。

在這些監控系統中，可以為關鍵指標設置一個閾值，當超過這個閾值時，隨叫隨到將會被傳呼。然而，這些閾值的設置，卻有可能是一把雙刃劍。如果閾值設置不當的話（即設置過低或過高），隨叫隨到可能會被大量傳呼所淹沒。閾值需要設置為只有在服務遇到問題時才會突破的值。同樣，工程師也不應過于熱心，為每個指標設置一個閾值。你需要警惕的是那些可以采取行動的指標，這些指標如果不能迅速解決的話，可能會產生毀滅性的影響。

減輕隨叫隨到的負擔并改善服務健康狀況的可行解決方案是自動化。如果某個問題不斷地重復出現，并且無需人工干預即可解決，那么就可以采用自動化。自動化系統可能會產生很大的影響，但如果不實施保障措施，可能會產生不良后果。例如，在重新啟動有狀態服務的實例時，不要同時重新啟動所有實例，這一點很重要。

自動化系統甚至可以與監控系統集成。只要達到特定指標的閾值，監控系統就可以觸發自動化。

為了防止人工操作造成問題和事故，必須保持高度的操作規范化。解決這個問題的一種方法是制定一個文檔完整的運行手冊，其中列出了每個手動操作的詳細步驟。最重要的是，另一個團隊成員可以驗證操作員的操作過程，特別是在已知操作會導致問題的情況下。

50% 的軟件工程都是維護服務的健康。這不是工作中微不足道的一部分。要知道，軟件工程并不僅僅是編寫代碼。

2. 代碼的可持續性

要確保任何推入的代碼都能靈活地應對變化是很重要的，當業務需求發生變化時，這一點尤為重要。

使用 DRY 原則

DRY 代表 “Don’t Repeat Yourself”。（不要重復自己寫的代碼）。同一段代碼不應在許多場合重復。如果你看到這種情況，那么可能需要對其進行抽象以避免出現冗余。這樣，如果你需要修改它的邏輯，只需在一個地方修改它即可。

始終測試

始終為你編寫的任何函數編寫測試用例。引入的任何新特性都不能破壞系統的現有狀態，這一點很重要。測試可能是乏味的，但它將會帶來巨大的回報。

架構優先

如果在編寫代碼時不考慮架構，這將會產生滾雪球效應。在編寫代碼時，要想想其他服務將如何與它進行交互，將來更新它有多容易，以及如何測試它。編寫代碼的方式應該是，如果需要交換一種邏輯，那么放入一個新的邏輯是很容易的。

使用常量

永遠不要硬編碼。相反，要使用常量。這樣，如果將來需要更新值，只需修改一次，而不是多次。

3. 采取主動

工程師永遠不應該停滯不前。他們應該努力成為團隊的領導者。為了在你的團隊中擴大你的影響力，你必須采取主動，并愿意接受你不喜歡的新任務。優秀工程師的標志就是他或她能夠在最少的幫助下解決新的挑戰。我已經開始更多地參與自己并不熟悉的服務的代碼評審。我敦促自己對關于邊緣案例或弱點的技術設計文檔進行更多的評論。我甚至和我的經理談過，讓我參與一些能夠幫助我加強自身弱點的項目。

強迫自己進入一個新領域，并不是你唯一應該做的事情。你還需要提前考慮團隊將面臨哪些挑戰，以及如何應對這些挑戰。在它成為一個真正的問題之前，一定要提前考慮并及早解決。積極主動是我目前正在學習的一項技能。希望通過對這些技能和目標的努力，我能夠在下一階段取得更好的成績。

在過去的一年來我學到了很多，我希望在未來的幾年里能學到更多。

作者介紹：

Yen Huang，Twitter 軟件工程師，曾在 Amazon 工作。畢業于康奈爾大學。

原文鏈接：

https://towardsdatascience.com/3-things-i-learned-as-an-engineer-at-twitter-fe9ac352f2eb