距離2016年過去兩年来候，本文談?wù)勛约簭募尤階廠，經(jīng)歷了應(yīng)用運維的統(tǒng)一逸雹，并目睹應(yīng)用運維變革至今的一些總結(jié)营搅。關(guān)于技術(shù)上的一些總結(jié)可以參考 --- 我們離Google SRE還有多遠(yuǎn)云挟？
在A廠應(yīng)用運維的簡稱是PE，每年離雙十一系統(tǒng)最近的一批人转质。從2010年原本分散的BU運維組織聚合到一起組成一個統(tǒng)一的應(yīng)用運維部門园欣。到了2016年，這一年是應(yīng)用運維變革的元年休蟹，一是外部沸枯，Google SRE一書中文版的發(fā)行，引起了一股潮流赂弓，業(yè)內(nèi)的運維團隊紛紛脫掉了運維的外衣绑榴，穿上SRE的馬甲。二是內(nèi)部盈魁，按照當(dāng)時組織架構(gòu)的調(diào)整翔怎，PE大部從原本組織架構(gòu)剝離，人員拆分到各個業(yè)務(wù)研發(fā)線备埃。至少從2016年開始丁屎，應(yīng)用運維無論從名稱上或是組織上都像走到了生命的終結(jié)點。
作為曾經(jīng)大PE團隊的一員拐纱，也經(jīng)歷過組織架構(gòu)變動的不適應(yīng)皮迟。但相比其他團隊，幸運的是我所在的團隊 --- 大數(shù)據(jù)PE團隊至今在A廠仍獨立存在辅搬。2016年調(diào)整之后仍然保持不變唯沮，和研發(fā)團隊不同屬一個事業(yè)部，一年后堪遂，2017年歸屬到大數(shù)據(jù)事業(yè)部介蛉，事業(yè)部內(nèi)部我們和研發(fā)團隊仍然保持獨立。
我們有作為一個獨立團隊存在的歸屬感溶褪，這種歸屬感帶來很強烈的凝聚力币旧。在大數(shù)據(jù)業(yè)務(wù)爆發(fā)，集團猿妈、公有云吹菱、專有云三塊數(shù)據(jù)戰(zhàn)場同時開戰(zhàn)，EB級的數(shù)據(jù)彭则、千萬個計算任務(wù)鳍刷，公有云服務(wù)幾萬用戶，在專有云快速搭建百套數(shù)據(jù)服務(wù)俯抖，并輸出團隊自主研發(fā)的運維管控平臺输瓜。連我們的競爭對手都感嘆我們用一個幾十人的團隊完成了他們上百人團隊還未完成的事。
我們有組建一個數(shù)據(jù)時代的幸運感，和其他PE團隊不同尤揣，大數(shù)據(jù)PE團隊成立較晚搔啊，如果不是整個數(shù)據(jù)之初所有數(shù)據(jù)團隊布局就是一個分布式的微服務(wù)架構(gòu)，可能就不會提前感知到傳統(tǒng)思維的局限性芹缔，如果不是強烈的自我變革的驅(qū)動力坯癣，就很可能被時代趨勢被迫變革，那樣的話錯過的是本該屬于我們的機會最欠。
我們更有一種職業(yè)的使命感示罗，雖然因為組織架構(gòu)變化遭遇過“信仰危機”，一度不知道自己依然是PE還是SRE芝硬，但其實內(nèi)心很清楚我們并不是純粹的研發(fā)團隊蚜点。我們想讓更多人理解我們的價值，我們希望更多人能加入我們拌阴，一起抓住屬于我們自己的機會绍绘。因此，是時候?qū)^去變革中的喜怒哀樂做一個總結(jié)迟赃，并感謝公司給予的機會和團隊給予我的幫助陪拘。
一、融入
2010年初纤壁，A廠實施數(shù)據(jù)戰(zhàn)略左刽，與之相應(yīng)成立了業(yè)務(wù)產(chǎn)品研發(fā)、基礎(chǔ)系統(tǒng)研發(fā)等相應(yīng)的研發(fā)團隊酌媒，大家朝著各自模塊“服務(wù)化”的目標(biāo)和組織方式開展起來欠痴，為什么要把服務(wù)化加上引號，因為服務(wù)化這三個字是一個具體的過程秒咨，并不是突然間就達到的終態(tài)喇辽。首先，各個模塊服務(wù)之間相互隔離雨席，互相不影響菩咨。初期非常典型的問題，就是一個作業(yè)把集群大部分機器內(nèi)存撐爆陡厘，而導(dǎo)致集群所有服務(wù)都無法正常抽米，雖然當(dāng)下這類的問題已經(jīng)比較罕見，但是隨著服務(wù)模塊的增加雏亚，隔離和互不影響是一直是整個系統(tǒng)演進優(yōu)化的命題之一缨硝。其次摩钙，服務(wù)要可以單獨發(fā)布罢低，互不影響。一直以來都是有限定、有約束的單獨發(fā)布网持，這個限定和約束的邊界雖隨著系統(tǒng)優(yōu)化不斷的被打破宜岛，可盲目樂觀的理解單獨發(fā)布，一定會陷入各種依賴問題和故障中功舀。最后萍倡，模塊服務(wù)的研發(fā)負(fù)責(zé)該模塊所有事情。是的辟汰，在微服務(wù)還未興起的時候列敲，數(shù)據(jù)業(yè)務(wù)的組織架構(gòu)就是研發(fā)負(fù)責(zé)所有工作，而那時作為運維團隊帖汞，是如何隨著系統(tǒng)演進融入到這個組織架里的呢戴而？
① 技術(shù)架構(gòu)能力上互補。在初期翩蘸，和專注于業(yè)務(wù)產(chǎn)品和代碼的研發(fā)相比所意，我們對硬件、系統(tǒng)催首、網(wǎng)絡(luò)的技術(shù)能力是能夠形成互補的扶踊。曾經(jīng)不知道哪位研發(fā)Leader頭腦一熱，覺得自己的服務(wù)是分布式且冗余（或者說應(yīng)該是冗余的）郎任，決定所有服務(wù)器統(tǒng)一硬件配置秧耗，結(jié)果導(dǎo)致存放集群元數(shù)據(jù)的Master單點運行在一臺沒有任何保護，普普通通SATA硬盤的服務(wù)器上涝滴，這對系統(tǒng)的穩(wěn)定性的風(fēng)險可想而知绣版。而如果我們僅僅提醒研發(fā)團隊?wèi)?yīng)將單點改為多點冗余，然后就等著版本上線歼疮？這也不切實際杂抽，因為這可能需要很長的改造時間，而且可能在初期這都不是優(yōu)先級最高的事情（往往業(yè)務(wù)功能初期優(yōu)先級更高）韩脏。隨著我們拿出一個短期可行的改造方案和研發(fā)團隊討論缩麸，通過HeartBeat+DRBD的方案，用成熟的主備方案緩解單點的問題赡矢，再采購硬件可冗余的服務(wù)器杭朱，減少服務(wù)器硬件帶來的風(fēng)險。雖然這不是根本的解決方案吹散，比如會存在腦裂弧械。但相別之前風(fēng)險已經(jīng)降低很多，短期內(nèi)的警報可以解除空民。研發(fā)可以將有限的資源去滿足業(yè)務(wù)初期其他更高優(yōu)先級的需求以換的生存時間刃唐。半年后羞迷，上線三節(jié)點設(shè)計的Master徹底解決元數(shù)據(jù)冗余的風(fēng)險問題。這樣的Case在初期特別多画饥，早期由于系統(tǒng)設(shè)計缺陷衔瓮、業(yè)務(wù)的壓力、人員緊缺的問題往往都是運維團隊融入組織抖甘，贏得認(rèn)可的絕佳機會热鞍。讓研發(fā)做所有事情的初衷是好的，使研發(fā)人員為自己寫的代碼買單衔彻，這樣就能考慮到軟件長期可維護性薇宠。可這在實際情況中可能只是一廂情愿艰额，或者需要付出慘痛的代價昼接。在我看來，要做任何事就必須先具備與之匹配的能力和責(zé)任悴晰，否則拔苗助長反而會危害到所有人的長期利益慢睡。
② TroubleShooting的能力，所有問題的Owner铡溪。在初期漂辐，我們往往特別關(guān)注排障問題，因為一個很小問題都很容易引起多個研發(fā)團隊相互扯皮棕硫。大家一會就沒有了頭緒髓涯。為什么會出現(xiàn)這樣的情況呢？A廠在最初的一兩年內(nèi)發(fā)布了多款重量級的產(chǎn)品哈扮，如此快的節(jié)奏背后的就是多個服務(wù)的不同疊加組合纬纪。將分布式存儲P+分布式調(diào)度F+協(xié)同服務(wù)N+通信服務(wù)K組成基礎(chǔ)服務(wù)，再與計算服務(wù)D結(jié)合為集團滑肉、公有云客戶提供數(shù)據(jù)存儲包各、計算、算法等等服務(wù)靶庙。好處是问畅，多個團隊高效協(xié)同發(fā)布，搶占市場先機六荒』つ罚可作為硬幣的另外一面，災(zāi)難性的排障過程掏击，每當(dāng)類似作業(yè)運行變慢或者性能間歇性的問題時卵皂，過程尤為痛苦。通常需要從F團隊叫人查到P團隊砚亭，再查到N團隊灯变，一直查下去豺旬，一個電話會議里通常5-6個團隊大家要么證明自己沒問題，要么說明自己負(fù)責(zé)的領(lǐng)域不屬于該問題柒凉，需要團隊其他人來響應(yīng)，大家你一言我一語篓跛，往往幾個小時過去膝捞，卻一點進展都沒有。久而久之愧沟，我們在大小各種問題的處理中就變成了主導(dǎo)蔬咬，我想這是因為作為一個全程參與所有問題的處理過程本身是學(xué)習(xí)任何系統(tǒng)的最快捷徑，所以從全局的角度來看沐寺，我們可能變成最了解系統(tǒng)全貌的團隊林艘。其次，我們不負(fù)責(zé)任何模塊混坞，往往站在如何快速解決當(dāng)下的問題狐援，和之前大家忙于證明自己的模塊是沒有問題是有本質(zhì)立場差別。最后究孕，在解決問題的電話會議里思路清晰不猶豫啥酱，做決策和Call正確的人，這些能力都漸漸讓其他團隊都愿意配合厨诸，最終提高了大家的效率镶殷，否則一出問題大家都要上來Standby，自證清白也不能離開干自己的事情是效率非常低下的微酬，在A廠數(shù)據(jù)業(yè)務(wù)產(chǎn)品演進過程中绘趋，一個核心模塊往往被組合成好幾個服務(wù)產(chǎn)品，要是每個產(chǎn)品出問題颗管，該核心模塊的人都要起來Standby陷遮，那么這個團隊根本沒有時間去做任何改進，可能查問題的人都不夠垦江。
③ 利用好全局觀拷呆，上帝視角。我們常說自己擁有一個系統(tǒng)的上帝視角疫粥，由于在初期缺乏有效的管理茬斧，和標(biāo)準(zhǔn)化的執(zhí)行力，加上業(yè)務(wù)的一路飛奔梗逮，出現(xiàn)過很多不識廬山真面目项秉，只緣身在此山中的問題。曾經(jīng)一個管理部署服務(wù)Y慷彤，服務(wù)D通過給集群的服務(wù)器打上相應(yīng)角色的標(biāo)簽來判斷需要啟動那些服務(wù)娄蔼，比如服務(wù)F怖喻、服務(wù)P等等，之前提到岁诉，一個計算服務(wù)D由服務(wù)F+P+N+K組成锚沸。不幸的是服務(wù)F實現(xiàn)過程中，又依賴部署服務(wù)Y的標(biāo)簽服務(wù)涕癣，這樣導(dǎo)致了一個高可用性要求服務(wù)（D依賴的F）依賴一個低可用性要求的服務(wù)（Y僅在部署時需要）哗蜈。這些看起來很簡單的問題其實也是分布式系統(tǒng)架構(gòu)的下的“副產(chǎn)品”，而我們正好通過上帝視角發(fā)現(xiàn)并解決很多這類問題坠韩。
回顧我們?nèi)谌氲倪^程距潘，無論是我們還是研發(fā)其實就像渡過一個蜜月時期，大家為了產(chǎn)品業(yè)務(wù)交付給客戶的最終價值而一起努力奮斗只搁，并且結(jié)下了彼此間信任的果實音比。相反，如果一談起運維洞翩，還停留在IT時代那種刻板印象，就未免就以偏概全焰望，雞同鴨講了柿估。包括我們在融入之初秫舌，自己就決定與IT運維的方式說再見的妖，這是什么原因呢？首先足陨，在IT時代嫂粟，系統(tǒng)面臨的吞吐量和延遲要求遠(yuǎn)不如今，系統(tǒng)環(huán)境相對簡單且封閉墨缘。其次星虹，軟件的開發(fā)迭代周期可以很長，常年很少做新功能類的升級镊讼。而且也不必考慮軟件擴展性宽涌，通常就是將業(yè)務(wù)按照地域、部門做切分蝶棋，在地域卸亮、部門內(nèi)部獨立部署支持，業(yè)務(wù)流和數(shù)據(jù)流很少互通玩裙。那么應(yīng)用的部署兼贸、擴容等場景相對要簡單很多段直。還有，研發(fā)語言要求統(tǒng)一溶诞，并且各個模塊耦合度高鸯檬，運行穩(wěn)定之后，就不太需要發(fā)生變化螺垢。為了保證這個穩(wěn)定態(tài)不受變化喧务，往往需要可靠的服務(wù)器（昂貴的小型機），冗余（小型機一臺不夠甩苛，雙機熱備，存儲RAID做數(shù)據(jù)冗余）俏站，數(shù)據(jù)備份（磁帶備份）讯蒲。此外，IT時代運維團隊將減少任何導(dǎo)致系統(tǒng)不可服務(wù)時間的工作（無論是人為疏忽還是發(fā)布）成為其最核心的KPI肄扎，為此如何建立的各種流程墨林，讓公司各個研發(fā)、測試和運維部門各司其職犯祠，高效協(xié)作是核心命題旭等。而現(xiàn)如今互聯(lián)網(wǎng)時代，特別是移動互聯(lián)時代衡载，如上所述的背景均已不復(fù)存在搔耕，例如，新的系統(tǒng)需要快速上線痰娱，上線后再根據(jù)用戶需求不斷發(fā)布更新迭代弃榨，升級非常頻繁。在譬如梨睁，由于系統(tǒng)的耦合度降低鲸睛，走向分布式，研發(fā)團隊小規(guī)钠潞兀化官辈，“服務(wù)化”。一個業(yè)務(wù)產(chǎn)品由不同的子服務(wù) — 服務(wù)A遍坟，需要服務(wù)B拳亿，服務(wù)C，服務(wù)D組合而成愿伴，這些服務(wù)可以由不同的語言风瘦，不同的架構(gòu)獨立研發(fā)并發(fā)布，但這樣給服務(wù)A的部署和穩(wěn)定性變的更加的復(fù)雜公般，和IT時代相比万搔，在互聯(lián)網(wǎng)時代下分布式胡桨，服務(wù)化架構(gòu)的影響下，我們面臨的問題更復(fù)雜，也更富有挑戰(zhàn)。
二抒线、變革
變革是渡過融入期之后想邦，我們討論思考最多的命題，這本身就是一個變革致扯、日新月異的時代。任何團隊或者組織的價值是都是交付客戶價值的鏈，在這個競爭市場中尚镰，大家Share的是相同的價值目標(biāo)，而不是Share相互之間的默契程度和對團隊邊界的墨守成規(guī)哪廓。所以再強調(diào)技術(shù)能力互補狗唉，TroubleShooting能力并不是我們的護城河，因為這些能力任何團隊作為價值鏈的一員都會具備涡真，而如果我們還再單純談成本優(yōu)化分俯、效率提升、配置管理而不關(guān)心團隊能力是否處于價值鏈中就可能很快消亡哆料。我們處于這個時代的趨勢中既幸運又焦慮缸剪，幸運的是我們也可以做任何事，焦慮的是時不待我东亦。那幾年杏节，我們常說如其讓別人來變革我們，不如我們自己變革自己典阵，從2013年起拢锹，我們內(nèi)部達成變革共識，那么我們是如何行動的呢萄喳？
① 具備研發(fā)能力卒稳，首先改變招聘策略。因為我們不能要求當(dāng)時團隊的每個同學(xué)人人都具備代碼能力他巨，所以我們改變了招聘的方式，在面試中增加代碼面試染突，以及邀請研發(fā)人員來交叉面試的環(huán)節(jié)捻爷。這是第一個陣痛期降宅，并且很長時間招不到合適的人選劣挫，業(yè)務(wù)的壓力還在蹭蹭的漲阎毅。其次涎拉，缺乏經(jīng)驗導(dǎo)致的“慣性恐懼”心里季俩。這是第二個陣痛期钮糖，外部對我們有認(rèn)知的慣性，即使看到我們的改變酌住，也常常帶有偏見店归，說我們就是野路子阎抒，不愿加入。內(nèi)部同學(xué)對自身也沒有信心娱节，也是人對一個未知領(lǐng)域的本能反應(yīng)挠蛉。有些人跟我說，“我們是運維肄满，不是研發(fā)谴古，不專業(yè)啊稠歉！”現(xiàn)在回過頭來看掰担，經(jīng)驗的缺失并不是技術(shù)問題，而是心里問題怒炸，就像有個小人在你腦海里復(fù)現(xiàn)带饱，告誡你不要離開舒適區(qū)，并且列舉很多原因讓你接受那是一個限制阅羹。而你要做的就是忽視和一笑而過勺疼。在A廠打響沖集群規(guī)模的技術(shù)攻堅戰(zhàn)時，其中負(fù)責(zé)部署的模塊已經(jīng)無法承擔(dān)更大集群規(guī)模的要求捏鱼，在這種背景下我們接手并改造了此模塊执庐。從人員上，原本屬于該模塊的研發(fā)人員并未加入我們导梆，我們短期內(nèi)也未招到一個合適的人轨淌。靠原本團隊內(nèi)部的研發(fā)能力（一邊白天處理線上問題看尼，一邊晚上碼代碼）递鹉，最后不僅完成了既定目標(biāo)，而且還將所有服務(wù)模塊的部署時間減半藏斩。最后躏结，渡過技術(shù)偏好的階段，這是第三個陣痛期狰域，當(dāng)人員招聘的情況得到改善媳拴，內(nèi)外部的環(huán)境逐漸打消了質(zhì)疑，原本一個很小的服務(wù)模塊也隨著業(yè)務(wù)發(fā)展承載了越來越多的場景北专，我們也開始對服務(wù)做內(nèi)部分層禀挫、子服務(wù)化的拆分，也開始建立CI/CD的流程拓颓，也開始治理發(fā)布之后一段時間沒有使用的模塊语婴，慢慢大家對技術(shù)偏好的執(zhí)著造成的摩擦越來越多，內(nèi)耗不可避免的嚴(yán)重起來。
② 培養(yǎng)產(chǎn)品思維砰左。具備產(chǎn)品思維的人是幾乎不能招到匿醒，只能培養(yǎng)。因為A廠的產(chǎn)品技術(shù)環(huán)境太特殊缠导，大部分產(chǎn)品都是自研為主廉羔。同時，我們在變革過程中也并非要求所有人必須向研發(fā)方向轉(zhuǎn)型僻造，對于那些常年在一線處理大小問題的關(guān)鍵同學(xué)來說憋他，一個問題他就是比別人要早定位、早解決髓削，那么強迫他去寫代碼竹挡，太浪費他的時間，更浪費團隊的時間立膛。相比研發(fā)能力揪罕，我們更希望培養(yǎng)他的產(chǎn)品思維。若沒有產(chǎn)品思維的思考宝泵，這樣的同學(xué)將永遠(yuǎn)陷入無盡的答疑和問題支持中好啰，成長空間有限。其次儿奶，作為解決問題思考延續(xù)框往，產(chǎn)品思維可以很好鍛煉從點到面的思考能力。有一款產(chǎn)品A廓握，問題非常多搅窿，不穩(wěn)定嘁酿，人員換了一批又一批隙券，反饋都是太亂，問題多等等闹司，直到有一個人干的不亦樂乎娱仔，我曾問他，“是因為產(chǎn)品問題收斂了嗎游桩？”他說牲迫，“沒有，但我認(rèn)為雖然問題很多借卧，但總逃不出那幾類盹憎。”大道至簡铐刘，殊途同歸陪每，讓事半功倍。在很長一段時間，特別是與高可用檩禾、可運維相關(guān)時挂签，我們就會被邀請參加研發(fā)團隊的新功能設(shè)計評審會參與討論。如果要在討論中讓他們快速理解痛點和初衷盼产，那么平時就要反復(fù)思考饵婆，能從解決單個問題的思路轉(zhuǎn)為產(chǎn)品設(shè)計的思維闡述。 最后戏售，產(chǎn)品思維的另一個好處是培養(yǎng)個人主動性侨核，Owner和服務(wù)意識，曾經(jīng)一位同學(xué)加入團隊之后有些不適應(yīng)灌灾，他跟我說芹关，“原來都是別人找我求助，為什么現(xiàn)在總要求我配合別人紧卒？”原本習(xí)慣了被動解決問題侥衬，現(xiàn)在需要了解更多的信息幫助主動思考，這種狀態(tài)本身也契合團隊變革的要求跑芳。
③ TPMs/技術(shù)運營轴总。一開始，我們培養(yǎng)技術(shù)運營能力博个，認(rèn)為技術(shù)運營目的就是讓更多人認(rèn)識并認(rèn)同我們怀樟。但在實際過程中，具備這些運營溝通能力的人往往很適合在重大緊急項目中發(fā)揮粘合的作用盆佣，特別是當(dāng)組織到了一定規(guī)模往堡，需要協(xié)調(diào)考慮的團隊太多的時候。一方面共耍，他/她們參與項目的始終虑灰，對其他團隊有非常好的溝通，他們的存在往往就是一個高效的流程機制痹兜。其次穆咐，他們往往對落地執(zhí)行的進度毫不退讓，有必要的訣竅解開團隊之間的“死結(jié)”字旭。最后对湃，他們作為技術(shù)團隊的意愿，有一定技術(shù)背景知識遗淳，在參與關(guān)鍵決策的過程中拍柒，建議不會被大家忽視。這樣的角色和Facebook的Technical Program Managers不謀而合屈暗，所以我們一度將技術(shù)運營改稱為TPMs拆讯。這一角色在A廠專有云輸出剧包，雙十一業(yè)務(wù)，混部項目中發(fā)揮了不可替代的作用往果，是團隊綜合影響力的體現(xiàn)疆液。
④ 新的團隊管理能力。事實上陕贮，除了以上三點能力的轉(zhuǎn)型堕油，我們也鼓勵人員向技術(shù)專精領(lǐng)域深入，特別是“老本行” — 系統(tǒng)肮之、網(wǎng)絡(luò)掉缺、硬件等方向。面對團隊多樣化的綜合能力要求戈擒，必須要有與之匹配的管理模式眶明，過去師傅帶徒弟的方式已經(jīng)不能滿足團隊轉(zhuǎn)型過程中人員的培養(yǎng)。作為技術(shù)Leader筐高，不僅有能力招到合適的人才搜囱，也要以身作則思考自己轉(zhuǎn)型的方向，同時柑土，對下屬人員有清晰的定位蜀肘，在經(jīng)驗上有能力提供指引，在不同能力定位上稽屏，需要具備開闊的眼界扮宠，能創(chuàng)造條件，讓人員有空間的發(fā)展狐榔。
由價值鏈輪來決定一個團隊的能力打破了各個團隊墨守成規(guī)的邊界坛增，運維不在是過去的運維，研發(fā)也不在是研發(fā)薄腻。這種發(fā)展的趨勢改變了架構(gòu)組織形式收捣，誕生的新的團隊方式。2016年當(dāng)集團發(fā)生組織架構(gòu)調(diào)整被廓，而我們繼續(xù)保持獨立那時起坏晦，我們明白萝玷，對我們來說嫁乘，沒有不變的職責(zé)，只有不變的團隊球碉，而不變的團隊總將消亡蜓斧，職責(zé)依然有人會繼續(xù)承擔(dān)，保持獨立我們也并不代表傳統(tǒng)睁冬，因為我們早已變革自己挎春。
三看疙、新的變革
終于整理到了尾聲，但轉(zhuǎn)型軌跡其實還未講完直奋。從2017年開始能庆，渡過了一個短暫的調(diào)整期之后，變革的腳步并沒有停下來〗畔撸現(xiàn)在不管是AIOps還是ChatOps的稱謂搁胆，我們都會有一種似是而非的感覺，但這也并不重要邮绿，永遠(yuǎn)不變的就是變化本身渠旁、接受變化的態(tài)度和付諸行動的決斷力，期待新的挑戰(zhàn)船逮。
