世界各地的系統管理員，祝賀您的專業假期！
我們已經沒有系統管理員了（好吧，差不多）。 然而，關於他們的傳說卻歷歷在目。 為了慶祝這個節日，我們準備了這部史詩。 親愛的讀者，放心吧。
曾幾何時，Dodo IS 的世界著火了。 那段至暗時刻，我們系統管理員的主要任務就是多活一天，不哭。
很久以前，程序員寫代碼又少又慢，每週只在 prod 上發布一次。 所以問題每 XNUMX 天只出現一次。 但後來他們開始編寫更多代碼並更頻繁地發布代碼，問題開始增加，有時一切都開始崩潰，回滾變得更糟。 系統管理員深受其害，但容忍了這場鬧劇。
晚上他們坐在家裡，心中充滿憂慮。 每次它發生時“它從未發生過，監控再次發出求救信號：伙計，世界著火了！”。 然後我們的系統管理員穿上紅色雨衣，在綁腿上穿短褲，在額頭上捲曲，飛去拯救渡渡鳥世界。
注意，稍微解釋一下。 在 Dodo IS 中從來沒有維護硬件的傳統系統管理員。 我們立即在 Azure 雲上取得進展。
他們做了什麼：
- 如果有東西壞了，他們會把它修好；
- 專家級別的服務器；
- 負責 Azure 中的虛擬網絡；
- 負責低級別的事情，例如，組件的交互（*竊竊私語*，有時他們不會摸索）；
- 服務器重新連接；
- 和許多其他野生動物。
基礎架構工程師團隊（我們稱其為系統管理員）的生活就是滅火和不斷破壞測試台。 他們生活並感到悲傷，然後他們決定思考：為什麼情況如此糟糕，或者我們可以做得更好？ 比如，我們不會把人分為程序員和系統管理員嗎？
問題
鑑於： 有一個系統管理員，他在他的職責範圍內有服務器，一個將他連接到其他服務器的網絡，基礎設施級程序（託管應用程序的網絡服務器，數據庫管理系統等）。 並且有一個程序員，其職責範圍是工作代碼。
還有一些東西在交界處。 這是誰的責任？
通常，我們的系統管理員和程序員就在這個交界處相遇，然後開始：
“伙計們，什麼都行不通，可能是因為基礎設施。
- 伙計，不，它在代碼中。
一天這時，他們之間開始長出一道籬笆，他們高興地通過籬笆扔便便。 這個任務，就像一坨便便，被從柵欄的一側扔到另一側。 與此同時，沒有人接近解決這一局面。 悲傷的笑臉。
幾年前在谷歌，當他們想到不交換任務，而是做一件共同的事情時，一縷陽光劃破了陰沉的天空。
但是，如果我們將一切都描述為代碼呢？
2016年，谷歌發布了一本名為《站點可靠性工程》的書，講述了系統管理員角色的轉變：從魔法大師到軟件和自動化使用方面的形式化工程方法。 他們自己經歷了所有的荊棘和障礙，掌握了竅門並決定與世界分享。 這本書在公共領域 .
這本書包含簡單的事實：
- 做任何事情都像代碼一樣好；
- 使用工程方法 - 很好；
- 做好監控是好的；
- 如果服務沒有明確的日誌記錄和監控，則阻止它被發布也很好。
我們的 Gleb 閱讀了這些做法（)，然後我們走了。 實施！ 現在我們正處於過渡階段。 SRE 團隊成立（有 6 名現成的專家，還有 6 名正在入職）並準備好改變完全由代碼組成的世界。
我們創建基礎架構的方式使開發人員能夠管理他們的環境並完全獨立地與 SRE 協作。
王而不是結論
系統管理員是一個有價值的職業。 但是系統部分的知識還需要出色的軟件工程技能。
系統變得越來越簡單，對管理鐵服務器的超級獨特知識的需求每年都在減少。 雲技術正在取代對這些知識的需求。
在不久的將來，一名優秀的系統管理員將必須具備良好的軟件工程技能。 更好的是，他應該在這方面有很好的技能。
沒有人知道如何在未來發生之前預測未來，但我們相信，隨著時間的推移，想要增加不斷膨脹的系統管理員人員的公司會越來越少。 當然，雖然粉絲會留下來。 今天騎馬的人很少，大多是用汽車，雖然也有情人……
祝大家系統管理員日快樂，給大家寫代碼！
來源： www.habr.com