序言

在上一篇文章中疆瑰，我們回顧了信息傳遞與處理在歷史長河中的變遷，也介紹了信息處理的架構(gòu)和關(guān)鍵要素昙啄，最后提出“軟件研發(fā)運(yùn)維的信息傳遞和處理如何優(yōu)化？” 我們能否讓每一位技術(shù)人員寸五，從需求梳凛、到開發(fā)、再到測試梳杏、運(yùn)維等……都生出三頭六臂韧拒？讓我們先看看軟件組織里面研發(fā)運(yùn)維在信息傳遞和處理上的典型現(xiàn)狀和挑戰(zhàn)淹接。

背景

A是一家互聯(lián)網(wǎng)公司的CIO，管理著眾多業(yè)務(wù)導(dǎo)向的交付團(tuán)隊(duì)和IT系統(tǒng)叛溢。交付團(tuán)隊(duì)分布在墨爾本塑悼、悉尼、西安楷掉、意大利等多個地點(diǎn)厢蒜，IT系統(tǒng)分別部署在公司機(jī)房、數(shù)據(jù)中心烹植、AWS斑鸦、國外的數(shù)據(jù)中心等多個地點(diǎn)。由于公司業(yè)務(wù)發(fā)展勢頭非常好草雕，該公司的交付團(tuán)隊(duì)（包括合作伙伴的團(tuán)隊(duì)）快速擴(kuò)張巷屿，IT系統(tǒng)的數(shù)量也越來越多，CIO發(fā)現(xiàn)自己陷入了疲于救火的狀態(tài)：

1. 分布式研發(fā)團(tuán)隊(duì)對于測試環(huán)境墩虹、發(fā)布窗口嘱巾、構(gòu)建能力等共享依賴資源的請求層出不窮，如何高效協(xié)調(diào)诫钓？
2. 分布式研發(fā)團(tuán)隊(duì)在集成旬昭、測試、發(fā)布等關(guān)鍵活動上的狀態(tài)變化頻繁尖坤，如何迅速傳播到相關(guān)團(tuán)隊(duì)與個人稳懒？
3. 分布式研發(fā)團(tuán)隊(duì)對于關(guān)鍵活動狀態(tài)的變化（構(gòu)建失敗、集成延期等）慢味，如何確保及時響應(yīng)和處理场梆？

B是一家金融機(jī)構(gòu)的運(yùn)維總監(jiān)，底下有多個運(yùn)維團(tuán)隊(duì)纯路，分布在上海或油、深圳、北京等多地驰唬。運(yùn)維部門負(fù)責(zé)維護(hù)該金融機(jī)構(gòu)數(shù)百個IT系統(tǒng)顶岸，對應(yīng)的考核指標(biāo)是99.99%的高可用性。每個不同地點(diǎn)的運(yùn)維人員都身兼數(shù)職叫编，需要對不同系統(tǒng)的不同異常事件進(jìn)行響應(yīng)和處理辖佣。為了保障4個9的高可用性，運(yùn)維總監(jiān)發(fā)現(xiàn)日常運(yùn)維中存在如下的難題：

1. 出現(xiàn)故障時搓逾，如何更有效地通知一線運(yùn)維個人卷谈，或者故障升級（Escalate）到二線處理小組？
2. 異常來自于不同的系統(tǒng)和監(jiān)控工具霞篡，除了告警之外世蔗，如何更有效地查詢異常的上下文信息端逼，進(jìn)行故障排查？
3. 分析異常之后污淋，如何確保異常故障被高效地響應(yīng)和處理顶滩？

分析

事實(shí)上，IT企業(yè)中的研發(fā)運(yùn)維基本都遵循著如下的流程框架寸爆，這個框架有著如下的特點(diǎn)：

軟件企業(yè)典型流程

• 存在大量的基礎(chǔ)設(shè)施礁鲁，以及圍繞著基礎(chǔ)設(shè)施的各類IT流程（需求、構(gòu)建而昨、部署救氯、測試、上線……）
• 基礎(chǔ)設(shè)施與IT流程產(chǎn)生了大量的數(shù)據(jù)歌憨，以及針對這些數(shù)據(jù)的分析和整理（流程改進(jìn)着憨、業(yè)務(wù)支撐、應(yīng)用支撐……）
• 前兩個階段產(chǎn)生了數(shù)據(jù)和信息务嫡，以及組織內(nèi)各角色的溝通甲抖、協(xié)作與下一步改進(jìn)（組織治理、知識庫心铃、改進(jìn)……）

縱觀整個流程准谚，機(jī)器、應(yīng)用持續(xù)不斷產(chǎn)生新的增加去扣、修改柱衔、狀態(tài)信息，這些信息需要被周密地分析和思考愉棱，不同的人要參與到這兩個過程唆铐，并且產(chǎn)生更多的知識、信息奔滑。簡而言之艾岂，這就是一個關(guān)于“人－機(jī)器（應(yīng)用）－信息”的管理問題，包含著如下的場景：

• 需求階段：如何確保需求的價(jià)值是值得投入的朋其？產(chǎn)品經(jīng)理可能需要做用戶研究王浴、用戶訪談，繪制NPS指標(biāo)來向管理層和團(tuán)隊(duì)溝通需求的價(jià)值
• 開發(fā)階段：如何確保系統(tǒng)的質(zhì)量（Quality）和完備度（Readiness）梅猿？項(xiàng)目經(jīng)理可能需要通過迭代氓辣、showcase，繪制燃盡圖袱蚓、CFD以及構(gòu)建頻率筛婉、構(gòu)建通過率之類的指標(biāo)，來揭示軟件系統(tǒng)的質(zhì)量和交付完備度
• 測試階段：如何確保系統(tǒng)的質(zhì)量和bugfix的效果？測試經(jīng)理可能需要收集bug發(fā)現(xiàn)的記錄爽撒，計(jì)算FFR或者缺陷率，來評估回歸測試以及bugfix的效果和質(zhì)量
• 運(yùn)維階段：如何確保系統(tǒng)的高可用以及業(yè)務(wù)連續(xù)性响蓉？運(yùn)維經(jīng)理需要收集系統(tǒng)運(yùn)行的數(shù)據(jù)和故障的數(shù)據(jù)硕勿，計(jì)算MTTR、MTTF等其它指標(biāo)枫甲，來衡量系統(tǒng)運(yùn)行的可靠性

挑戰(zhàn)

上一篇博客中提到了消息處理四要素：消息源武、輸入者、處理者想幻、消息網(wǎng)絡(luò)粱栖。對應(yīng)到軟件組織的研發(fā)運(yùn)維流程，我們可以發(fā)現(xiàn)：

• 輸入源：物理基礎(chǔ)設(shè)施脏毯、虛擬化平臺闹究、云管理平臺、虛擬機(jī)操作系統(tǒng)食店、中間件渣淤、數(shù)據(jù)庫、應(yīng)用程序吉嫩、網(wǎng)絡(luò)等
• 處理任務(wù)：創(chuàng)建一臺虛擬機(jī)价认、彈性擴(kuò)容、配置中間件自娩、數(shù)據(jù)庫用踩、配置應(yīng)用程序、部署新版本應(yīng)用程序忙迁、刪除機(jī)器脐彩、告警、推送消息
• 協(xié)作網(wǎng)絡(luò)：運(yùn)維一动漾、二丁屎、三線處理人員、開發(fā)人員（分布式）旱眯、需求人員晨川、測試人員、管理人員等

信息處理四要素

一個典型的IT流程包括：從故障源采集環(huán)境信息删豺，關(guān)聯(lián)不同的環(huán)境信息共虑，分析故障根因，采取行動（展示呀页、推送妈拌、處理、通知）、固化知識尘分。但是猜惋，當(dāng)處理故障的規(guī)模放大，面對著多系統(tǒng)培愁、多團(tuán)隊(duì)的軟件組織著摔，如何能夠高效地完成信息的采集、傳遞和處理定续？讓上文中的CIO和運(yùn)維總監(jiān)不再發(fā)愁谍咆？信息未來肯定是爆炸的，但是靠人來管理和協(xié)調(diào)肯定是無法滿足研發(fā)運(yùn)維過程的協(xié)作和溝通的私股。如何解決這個問題呢摹察？

ChatOps方案

以機(jī)器人為中心的ChatOps

我們先來看看一個典型的ChatOps例子：

ChatOps完成自動化部署

在這個例子中，人可以隨意地與機(jī)器人進(jìn)行溝通倡鲸，通過向機(jī)器人下指令供嚎，讓機(jī)器人完成應(yīng)用部署、部署狀態(tài)檢查等任務(wù)旦签，再也不用喊嗓子叫桌子對面或者辦公室另一個角落的運(yùn)維人員來做這件事情了查坪。優(yōu)雅，安靜宁炫。

什么是ChatOps偿曙？

ChatOps在很大程度上是由GitHub發(fā)起并推動的新趨勢。簡單地說羔巢，就是通過聊天機(jī)器人來完成自動化的指令望忆，以及通過聊天機(jī)器人來自動推送輸入需要的信息。為了實(shí)現(xiàn)ChatOps竿秆，一是需要把工具與機(jī)器人放在了溝通與協(xié)作的核心樞紐启摄，二是需要完成現(xiàn)有研發(fā)、運(yùn)維工作任務(wù)的梳理幽钢、標(biāo)準(zhǔn)化和自動化歉备。

ChatOps概念圖

ChatOps能夠集成并自動完成的場景有：

• 代碼管理系統(tǒng)：GitHub／GitLab - 采集代碼變更的提交信息以及狀態(tài)
• 持續(xù)集成系統(tǒng)：Jenkins／GoCD - 采集代碼持續(xù)構(gòu)建、集成的任務(wù)信息與狀態(tài)
• 需求任務(wù)管理系統(tǒng)：Trello／Jira - 采集需求任務(wù)的信息與流轉(zhuǎn)狀態(tài)
• 運(yùn)維監(jiān)控系統(tǒng)：Zabbix／PagerDuty - 采集運(yùn)維監(jiān)控系統(tǒng)的監(jiān)控狀態(tài)和事件
• 運(yùn)維工單系統(tǒng)：ITIL／ZenDesk - 采集運(yùn)維事件和工單的任務(wù)和狀態(tài)
• 其他辦公系統(tǒng)：gdoc／dropbox - 采集其他辦公系統(tǒng)的文檔狀態(tài)和事件
• ……

借助于ChatOps的自動化指令和規(guī)則匪燕，機(jī)器人能夠代替人完成絕大部分的檢索蕾羊、響應(yīng)和處理的工作；借助于ChatOps的機(jī)器人網(wǎng)絡(luò)帽驯，信息處理的效率可以水平擴(kuò)展龟再，大大滿足軟件企業(yè)研發(fā)運(yùn)維過程中信息爆炸的挑戰(zhàn)。

ChatOps示例

下面以ScaleWorks ChatOps為例尼变，分別展示進(jìn)入聊天頻道利凑、聊天頻道內(nèi)以及自動化指令的系統(tǒng)截圖，可以很清楚地看出來ChatOps的使用效果。

ChatOps效果圖

真正的足不出戶哀澈，家事牌借、國事、天下事日丹，事事關(guān)心

ChatOps落地路線

國外的ChatOps工具主要有Slack走哺、Hubot、Lita等哲虾，國內(nèi)的典型工具可以算阿里的釘釘和騰訊的微信。這些工具提供了完善的溝通協(xié)作API择示，通過廣泛的ISV支持了不同場景的自動化和服務(wù)束凑，譬如OA辦公、系統(tǒng)監(jiān)控以及其它服務(wù)等等栅盲。

對于自身能力比較強(qiáng)的技術(shù)公司汪诉，也可以通過引入開源的、免費(fèi)工具鏈谈秫，打造一套符合自身的運(yùn)維協(xié)作體系以及ChatOps平臺扒寄，比較有名的產(chǎn)品包括Hubot、Lita等拟烫。

但是该编，無論是商業(yè)產(chǎn)品抑或開源產(chǎn)品，建議按照如下的節(jié)奏進(jìn)行“三步走”的系統(tǒng)規(guī)劃與建設(shè)：

ChatOps落地路線

展望

硅谷大佬Mark Andreessen提出了一個觀點(diǎn)硕淑，“Software is eating the world”课竣。傳統(tǒng)行業(yè)不斷地被軟件侵蝕：Uber顛覆了taxis、WhatsApp顛覆了短信聊天置媳、Fibit／Keep顛覆了健身業(yè)于樟、Netflix顛覆了電影業(yè)……不勝枚舉，ChatOps開始顛覆軟件企業(yè)的信息處理也就順理成章了拇囊。在現(xiàn)在的時代迂曲，依賴于文山會海、郵件往來進(jìn)行信息傳遞和決策的企業(yè)寥袭，無法戰(zhàn)勝通過即時聊天和自動化機(jī)器人來處理信息的競爭對手路捧。

眼光再放長遠(yuǎn)，萬物互聯(lián)將是必然纠永，人機(jī)接口（HCI）將不可避免地朝著最簡單的方式演進(jìn)鬓长，直至有一天，進(jìn)化成為腦機(jī)接口（BCI）尝江。到了那一天涉波，Arthur Clark在其著作《2001太空漫游》中給出的HAL 9000機(jī)器人或許將成為人類最好的朋友。人類端坐在網(wǎng)絡(luò)中央，等著不同邊界不同節(jié)點(diǎn)處理好的信息進(jìn)入最終的大腦啤覆；大腦的指令下發(fā)到不同邊界不同節(jié)點(diǎn)苍日，每個節(jié)點(diǎn)完成信息的處理。

正如風(fēng)起于青萍之末窗声，新的協(xié)作模式并不是“大炮一聲響相恃，換了人間”。ChatOps代表著團(tuán)隊(duì)集體式智慧決策以及處理信息的方式笨觅，將不斷推動著手工工作的自動化和協(xié)作組織的方式拦耐。正如Kevin Kelly（KK）在《失控》一書中指出，"技術(shù)是生命體的第七種存在见剩。人類目前已定義的生命形態(tài)包括植物杀糯、動物、原生生物苍苞、真菌固翰、原細(xì)菌、真細(xì)菌羹呵，而技術(shù)應(yīng)是之后的新一種生命形態(tài)"骂际。

信然。

后記

文章剛收筆冈欢，又看到這篇新聞《“AlphaGo”不只會下圍棋歉铝，還將為Google節(jié)約15%的數(shù)據(jù)中心用電》——

從今年開始，Google 讓 DeepMind AI “接管”了部分?jǐn)?shù)據(jù)中心里的一些控制單元涛癌，從簡單一些的風(fēng)扇犯戏、空調(diào)和窗戶，到復(fù)雜的服務(wù)器本身拳话，最后節(jié)約了“幾個百分點(diǎn)”的電力先匪。經(jīng)過復(fù)雜的計(jì)算模型折算后，DeepMind AI 大約提高了 Google 15% 的能源使用效率……

過去，上面提到的很多開關(guān)和控制單元都需要維護(hù)人員手動操作——畢竟，人的力量還是有限的臭脓，而 DeepMind AI 卻有著無限的擴(kuò)展能力。

萬物互聯(lián)以及“機(jī)器人”對物理世界的進(jìn)擊速度岸裙，永遠(yuǎn)超出人類的想象。