資訊專欄INFORMATION COLUMN
摘要：運維友好的應用當開發更多的參與運維的工作后，切身的體會到需要改進的痛點后，變化就來了。比如，開發出運維友好的應用。什么是運維友好的應用在這篇論文里提到運維友好的應用幾乎不需要人工干預，極個別難解的故障外都可以被自動檢測并恢復。
dev+ops?
對于devops的理解，似乎很長一段時間都在混沌狀態。這很像早期網格計算，云計算初期每個人解讀的版本各有不同。同一本圣經，最后還不是由于不同信徒的解讀導致產生了天主教，東正教，新教的各種分支嗎？ 所以解讀很重要。
傳統上，大家認為devops就是讓dev干ops的活，干掉ops這個崗位，給老板省錢。小企業用云廠商方式搭建的應用上（其實還是要有懂ops的人）似乎可以這么搞，持有大規模私有云的企業適合這么干嗎？
這兩個詞合在一起其實可以從兩個方向看：
dev >> ops
很明顯，這是要dev有運維能力，加運維技能點。
dev << ops
反過來，運維為了減少人肉，要有開發能力，開發自己需要的系統，進行自動化運維。
兩個方向合力，各自都在自己的地盤上多跨一腳，成就了別人，也造就了自己。我們想要的就是在工程效率上的提升。
Google的devops這件事上Google繼續領跑，去年Google出了一本書《Site Reliability Engineering》給出了答案，SRE就是Google版本devops的最佳實踐。
其指導思想就是開辟了SRE崗位，讓此崗位的人具備研發能力，自研支撐系統來代替傳統上各種需要人工操作的地方，保證系統規模不斷擴大時系統工程師別跟著線性增長。SRE招聘上有兩類：一類與正常的軟件工程師技能要求一樣；另一類工程師技能可能稍弱但有其他技能（UNIX內核，三層網絡）加成。
devops作為一種開發模式的轉變，我認為其提供的其中一種積極的作用在于，讓傳統上分裂的開發和運維部門更多的協作，而不是對立。
例如開發關注點在于功能的交付，運維關注點在于系統穩定和安全。通常一個渣渣系統出問題，可能半夜先被叫醒的是Ops而不是Dev，當Dev不深受其苦時其系統穩定性是沒有內在動力的。
運維友好的應用當開發更多的參與運維的工作后，切身的體會到需要改進的痛點后，變化就來了。比如， 開發出運維友好的應用。
什么是運維友好的應用？
James Hamilton 在Windows Live Services Platform 2007這篇論文里提到：
While auto-administration is important, the most important factor is actually the service itself. Is the service efficient to auto- mate? Is it what we refer to more generally as operations-friendly? Services that are operations- friendly require little human intervention, and both detect and recover from all but the most obscure failures without administrative intervention.
運維友好的應用幾乎不需要人工干預，極個別難解的故障外都可以被自動檢測并恢復。
此文章主要介紹了Windows Live Search團隊在交付運維友好的服務時總結的最佳實踐，如今仍然有指導意義。此處不做展開，文末引申閱讀里列出了下載地址，可自行觀看。
Design for failure開源界典型的業界范例可以參考Netflix貢獻的eurka，DropWizard等產品的設計思路，此類基礎程序在設計之初就考慮到了分布式系統的容錯，系統監控自包含并提供http接口和簡單圖形界面。
以Eureka為例，作為設計在云計算環境使用的服務發現組件，認為服務失效是個常態，所以在服務失效時客戶端代碼有本地緩存，會自動將請求分發到一臺新的服務地址上，實現故障轉移。 而Eureka的服務端，會對發布在其上的服務器進行健康監測，在心跳緩慢或丟失時自動將服務器剔除，達到自動容災的目的。
此處可引出很多內容（自我保護，容災，限流，降級，監控，分組隔離，進程隔離，線程隔離，容量規劃，基線管理，超時控制，重試控制，無狀態化），真要聊，還是另開場地吧~
方便的監控現代服務都有良好的后臺，方便的看到系統內部狀態，eureka 界面如下：
eureka也被集成到了spring cloud中作為服務發現的組件，其界面也是大同小異的：
由上也可看出，什么叫運維友好？自己的服務，能在一處統一的地方看到內部的運行狀態，這在觀測系統行為和排查問題時是極為有用的。
依賴控制java依賴通過maven控制，為啥系統依賴要割裂出來用各種基線來控制呢？還是用docker image解決系統級的依賴吧，不過似乎大多數java應用除了jdk,tomcat其實也不需要太多此種依賴，除了外掛的各種采集類的agent。
自動化最近Gitlab.com發生的刪庫后，陳皓的一篇文章闡述了一個觀點
一個公司的運維能力的強弱和你上線上環境敲命令是有關的，你越是喜歡上線敲命令你的運維能力就越弱，越是通過自動化來處理問題，你的運維能力就越強。
這是必要的，按照規范將大量繁雜活自動化，命令都固化到腳本或程序中去，讓程序準確無誤地執行。
好了，就這么多了，歡迎拍磚
—
延伸閱讀：
On Designing and Deploying Internet-Scale Services
為什么不應該使用ZooKeeper做服務發現
理解Eureka的自我保護模式
Netflix源碼解析之Eureka：Eureka client 注冊過程
從GITLAB誤刪除數據庫想到的)
本文來自微信公眾號「麥芽面包，id「darkjune_think」
轉載請注明。
微信掃一掃關注公眾號。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/7987.html
摘要：運維部門比較笨，他們不懂新技術，為什么他們沒法實現最新的技術呢為什么他們這么落伍呢在我的機器上運行的沒問題啊刺客聯盟與圣殿騎士互掐了幾百年，但事實上他倆都不過是想維護人類文明開發與運維互看不順眼，但他們的初心都是想這個項目能順利驗收。 從電子游戲到DevOps在一個項目團隊中，開發與運維之間的關系像極了知名大型游戲《刺客信條》里的故事：開發就是追求自由的刺客聯盟——我喜歡用各種新穎技術...
摘要：當云平臺出現網絡故障系統故障等問題，這對云租戶用戶有時甚至是致命的，所以不少是由高級別開發人員轉型而來。目前國內各大云廠商也基本都提供了應用運維平臺，包括騰訊藍鯨阿里華為等。 DevOps 全鏈路 下圖是我們熟知的軟件研發環節，在迭代頻率高的研發組織里，一天可能要經歷多次如下循環。對于用戶群體龐大或者正在經歷大幅業務擴張的企業研發組織，除了重點關注應用的快速上線之外，如何保障應用的高可...
摘要：編者按本文作者為，主要介紹告警疲勞的產生原因與對抗告警疲勞的種方法。告警疲勞不僅會影響團隊成員的工作情緒，而且會阻礙軟件交付鏈的成長。利用工具事件管理工具對抵抗告警疲勞大有幫助。 【編者按】本文作者為 Chris Riley，主要介紹告警疲勞的產生原因與對抗告警疲勞的8種方法。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。 各司其職、孤軍作戰非常不利于團隊溝通，一旦發生重大事...
摘要：此文已由作者林帆授權網易云社區發布。好在問題發生在工作時間，被及時發現，沒有導致什么損失。此外，服務的安全性也逐漸需要提上日程。這種應用與云高度融合的實踐算得上是的一種終極形態。 此文已由作者林帆授權網易云社區發布。 歡迎訪問網易云社區，了解更多網易技術產品運營經驗。 序文伴隨著IaaS、PaaS等云端基礎設施技術的成熟，應用上云成為許多企業軟件部門的心頭大事。通過把傳統軟件系統搬到云...
摘要：作為本次大會的白金贊助商，華為云作為容器技術的領導者之一，將如何展現自身能力讓小編先帶你一睹為快。華為云如何參與本次峰會技術直擊熱點自去年以來，存儲一直是大會的熱點。今日，2018年容器領域最大的峰會之一KubeCon ＋ CloudNativeCon于丹麥哥本哈根召開。云計算業界領先公司和技術大牛將齊聚童話王國一同交流和分享容器技術。作為本次大會的白金贊助商，華為云作為容器技術的領導者之一...
閱讀 1336·2023-04-25 23:47
閱讀 912·2021-11-23 09:51
閱讀 4432·2021-09-26 10:17
閱讀 3706·2021-09-10 11:19
閱讀 3254·2021-09-06 15:10
閱讀 3546·2019-08-30 12:49
閱讀 2421·2019-08-29 13:20
閱讀 1730·2019-08-28 18:14
