資訊專欄INFORMATION COLUMN
摘要：等研發介入時，現場已經不復存在。因此，我要求戒律一凡是中間件，不管是自主研發的，還是以開源軟件為內核構建出來的，都必須自帶監控報警，否則不允許上線。
鄭昀（公眾號：老兵筆記） 20180411
如果你在繁忙的業務迭代中開始系統重構，恭喜你，說明你的業務已經完成了從0到1，正在從1走向10，或者從10走向100。
至于重構后的技術棧是 Spring MVC+Dubbo，還是 Spring Boot+Spring Cloud？
是 Vue+ElementUI，是 React，還是 Ant.design，抑或就是上古時代的 JQuery+Bootstrap？
是 k8s，還是 mesos+marathon？是 Thrift，還是 Hessian，抑或 Protobuf？我并不在意。
我并不 care 這些東西，每個技術團隊都可以有自己的技術選型思路。
我在意的是兩個“是否有利于”：
一，是否有利于發布部署。
二，是否有利于排除故障（是否有利于快速定位線上問題和解決問題）。
為什么要強調它倆？
因為我們在過去六七年間，經歷了太多的生死折磨。如履薄冰如臨深淵。
我們曾是做本地生活服務電商的，餐飲/電影/酒店/景點門票/美容美發……
節假日往往也是本地生活服務的峰值日，飯點兒就相當于秒殺。
太多次在假期被召回。
太多次打電話給各個 TeamLeader，有時電腦不在身邊，有時深山老林無法上網，有時無人接聽，有時 VPN 連不進去～
多少次翹首期盼 DBA、SA、QA、DevManager 們給我回報到底出啥事兒了。
請先閱讀一下我寫的《經歷不可抗力是一種什么體驗》，了解一下什么是 too young too naive。
以至于我有兩個怨念：
怨念一，Centreon 爛到渣，Zabbix 也不咋的，基礎運維的那些神兵利器，都不考慮做業務的人，尤其是業務集群規模龐大的人，到底是怎么排查問題排除故障的。
SA 是怎么工作的？
一旦出現連接數暴漲，Web/App 服務長時間無響應，應用內存飆升，SA 拍馬趕到，一定是先重啟相關應用（不管是容器還是虛擬機），如果還不管用，就立即將相關應用悉數回滾到上一個穩定版本上，爭取以最短時間恢復。
等研發介入時，現場已經不復存在。
六七年前，事發后，我們登入 Centreon 和 ELK，按機器組、按機器、按指標，用肉眼，用大腦，結合各個業務集群里的日志，結合 Nagios 報警短信，理出來一個因果證據鏈。
你可能需要打開幾百個監控頁面，你還需要精通業務集群的分組、調用關系和IP（那時候還沒有 Docker 容器，都是虛擬機）。
這也就是為什么我定下我司研發哲學第一條：Don"t make me think……
怨念二，開源軟件的開發者是好人也往往是性情中人，不太考慮排除故障成本低、可視化、高可用、可伸縮、監控報警等商業系統必備的運維屬性，拿來主義必死無葬身之地。
舉個例子吧，ActiveMQ 和 RabbitMQ 有生產者流量控制，如果你沒有聽說過，沒有遇到過，恭喜你，但也表明你的業務量還是太小。
你可能會說，遇到了生產者流量控制，說明下游消費者消費得太慢，加快速度不就完了？
在電商服務中，異步消息隊列的消費者往往是與第三方系統網絡通訊，第三方系統可就不在你控制范圍之內了，一個第三方系統掛了，或者突然擁塞，就會憋住你的消費者集群的所有線程，造成消息積壓。因此就將上游生產者掛起？開玩笑呢吧？！咋想的這都是？讓災難從下游蔓延到上游？！
那么我們應該怎么思考系統重構呢？
隨著業務規模越來越大，隨著應用越來越多，隨著 Docker 容器集群的引入，隨著前后端分離導致內部接口越來越多，隨著 API 網關的引入，我們越來越難以在5分鐘之內斷定系統出了什么事兒。
因此，我要求：
戒律一：凡是中間件，不管是自主研發的，還是以開源軟件為內核構建出來的，都必須自帶監控報警，否則不允許上線。
戒律二：本著 Don"t make me think 的哲學思路，所有對排除故障有幫助的信息，都必須一站式展示在交互界面上，也就是在中間件的控制臺上，或運維自動化平臺上，或研發協作平臺上。
下面舉一些具體的例子，幫助大家理解。
我司的技術支撐體系如下圖所示（或點擊查看原圖）：
其中：
1，定時任務管理與調度平臺有運行情況展示，自帶監控報警：
2，異步消息可靠推送系統有可視化的內部詳情展示，自帶監控報警：
3，分布式并行計算調度與管理平臺一站式展示工作流下每一個任務在所有節點上的運行日志，并自帶監控報警：
4，大數據協作平臺自帶監控報警：
5，我們甚至要把所有 PC 客戶端，所有智能設備都監管起來：
6，研發協作平臺一站式展示應用部署的方方面面：
可以說我們打造的每一個中間件、協作平臺都體現了戒律一和戒律二。
不需要東奔西走，四處收集蛛絲馬跡。
不需要一次性點開幾百個指標頁面，腦補推演。
不需要精通集群部署結構。
不需要熟知應用日志的路徑。
對，這就是為我這樣的“旁觀者”、“小白”準備的。
有了這些系統，即使大家都出去玩了，我一個人也能看出問題所在，同時也能有效應對鐵打營盤流水兵的情況。
當你完成了從0到1的跨越，正在從1走向10，走向100，請記住下面的忠言：
兩個“是否有利于”：
一，是否有利于發布部署。
二，是否有利于排除故障（是否有利于快速定位問題和解決問題）。
兩個戒律：
戒律一：凡是中間件，不管是自主開發的，還是以開源軟件為內核構建出來的，都必須自帶監控報警，否則不允許上線。
戒律二：本著 Don"t make me think 的哲學思路，所有對排除故障有幫助的信息，都必須一站式展示在交互界面上，也就是中間件的控制臺上，或運維自動化平臺上，或研發協作平臺上。
-EOF-
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8034.html
摘要：關于與的區別，網上已經有不少文章了，在此不多談。主要想談的是在制作網頁時，什么時候設定字體大小用，什么時候用先談結論，再講為什么。一般情況下，還是以用為主，只有當需要在不同設備上顯示不同大小的字體時，再用。 關于rem與px的區別，網上已經有不少文章了，在此不多談。主要想談的是：在制作網頁時，什么時候設定字體大小用px，什么時候用rem？ 先談結論，再講為什么。一般情況下，還是以用px...
摘要：本章我們來聊聊重構造成的災難性毀滅。看到這里即可明白重構造成的災難性毀滅是在年的時期發生的，那個階段在技術不夠扎實但還有一股子改變世界的勁頭發生的問題。 showImg(https://segmentfault.com/img/bVbjDK2?w=1734&h=682); 前言 這章我在7月20號的時候就準備好了標題，在那之前有寫過一篇重構的文章，這段時間一直在等重構造成的弊端。 慶幸...
摘要：本章我們來聊聊重構造成的災難性毀滅。看到這里即可明白重構造成的災難性毀滅是在年的時期發生的，那個階段在技術不夠扎實但還有一股子改變世界的勁頭發生的問題。 showImg(https://segmentfault.com/img/bVbjDK2?w=1734&h=682); 前言 這章我在7月20號的時候就準備好了標題，在那之前有寫過一篇重構的文章，這段時間一直在等重構造成的弊端。 慶幸...
摘要：前端切圖神器前端掘金安裝前端的基礎工作就是把設計師的設計稿還原成前端頁面，所以切圖是作為一個前端的基本技能。 騰訊 Web 工程師的前端書單 - 閱讀 - 掘金作者：link 2014年一月以來，自己接觸web前端開發已經兩年多了，記錄一下自己前端學習路上看過的，以及道聽途說的一些書，基本上按照由淺入深來介紹。 JavaScript 入門 《JavaScript權威指南（第六版）》 ★...
摘要：服務端任需要進行校驗來達到數據的可靠性前端的路由可能在服務端并不存在等等這一系列重用性的問題。串行并行，大幅縮短請求時間。關于作者本人主頁本文部分圖片段落參考文章淘寶前后端分離實踐微信公眾號會不定期推送前端技術文章，歡迎關注 一、背景 書接上文，淺談前后端分離與實踐(一) 我們用mock服務器搭建起來了自己的前端數據模擬服務，前后端開發過程中只需定義好接口規范，便可以相互進行各自的開發...
閱讀 1630·2023-04-25 18:19
閱讀 2078·2021-10-26 09:48
閱讀 1079·2021-10-09 09:44
閱讀 1730·2021-09-09 11:35
閱讀 3027·2019-08-30 15:54
閱讀 2020·2019-08-30 11:26
閱讀 2285·2019-08-29 17:06
閱讀 884·2019-08-29 16:38
