信息技術：運維跟開發(fā)一定有仇嗎?開發(fā)能在多大程度上幫助運維減輕半夜被叫起的負擔?
這是一篇命題作文：《運維跟開發(fā)一定有仇嗎?開發(fā)能在多大程度上幫助運維減輕半夜被叫起的負擔?》，是應一位同行兄弟的邀請而作此文。他告訴我，目前他所屬的運維跟開發(fā)的關系有些僵持，希望能我能發(fā)表一些看法。盡管我不一定能給出好的建議，但我覺得這個事情應該具有一定的普遍性，于是就答應寫一篇開發(fā)和運維的關系協(xié)調的文字，權作拋磚引玉。
總所周知，一個網(wǎng)站或者一個項目要創(chuàng)建、開發(fā)和運營，絕不是一個人可以完成的(個人玩玩那種不算)。至少需要產(chǎn)品、設計、程序開發(fā)(前端、后臺)、測試、系統(tǒng)維護(部署、運營、維護)、平臺運營等等若干職位。
在團隊的認知中，某些職位的人總喜歡強勢認為自己很重要，是處于主導地位的。于是在這些人的意識里，其它職位或人員都是輔助和次要的，是圍繞著他的。在這樣的環(huán)境里，造成人員沖突的幾率就大，相互協(xié)作的意識就幾乎不存在。如果項目最高領導(老板)也有這種認識，那么情況就更加糟糕。
我司我組的運維都看著挺辛苦的，經(jīng)常半夜兩三點起來處理故障問題，因為經(jīng)常有致命告警。他們往往對某些實現(xiàn)上的細節(jié)不清楚，所以也很有可能把主導項目的開發(fā)leader叫起來，于是大家都在深更半夜不太清醒的狀態(tài)下處理故障。從經(jīng)常半夜兩三點發(fā)生致命告警，到經(jīng)常半夜兩三點不太清醒的狀態(tài)下處理故障，再到經(jīng)常半夜兩三點發(fā)生致命告警——胳膊要有胳膊的覺悟，你是扭不過大腦的。
不管哪種情況，作為小開發(fā)，該管的事是“提出問題”，而不是“怎么解決問題”。三更半夜運維接告警有幾種：
1、硬件告警，如內存錯誤/Raid降級類，這種基本上通過冗余等方式解決
2、外企，服務對象是國外客戶有時差，這個以前是叫應用運維，現(xiàn)在是叫SRE/DEVOPS解決，項目詳細的拋錯代碼及對應解決方案wiki，監(jiān)控是全流程的埋點，可以很快定位是哪里有壓力或者瓶頸。至于打印堆棧/dump內存這種，看貴司花多少錢招來的運維吧，5000的運維肯定是干不了的；
3、晚上定時任務類的，大數(shù)據(jù)處理類的，這種基本放到凌晨跑，出了故障也比較常見，基本上運維可以解決。
在大部分不規(guī)范的或者不是以技術做驅動的公司里，一個比較典型的情況就是：對于系統(tǒng)運維人員，如果系統(tǒng)長期穩(wěn)定運行，一些人就會認為，這些人是不是多余的?反之，如果故障頻發(fā)，一些人有開始抱怨，運維是干啥的啊，怎么老出問題?
是不是說如果開發(fā)把功能做得完備些，特別是在上線前多測試演練，多在可能故障的地方埋點以幫助在意外情況下可以恢復到一個慢但準確的Plan B的執(zhí)行路徑上來，這樣哪怕運維半夜被叫醒，也可以快速遷到plan B，不至于人為操作半天，畢竟運維不在清醒情況下更容易出問題。
所以總覺得運維如此辛苦，是因為開發(fā)在開發(fā)環(huán)節(jié)：
1)沒有用心把系統(tǒng)做得故障冗余
2)沒有重視上線前測試演練
3)沒有配合和敦促運維一起做好面板監(jiān)控和自動化處理(于是乎總要通過慢的命令行的人工操作)的結果。
....
這樣的僅僅從一方找原因的分析結果讓我聯(lián)想到餐廳清潔工抱怨的故事。以前我聽到過餐廳清潔工埋怨客人把地方弄得太臟，導致她們工作很辛苦。但是這里有個悖論：如果客人素質都非常高，不僅不會不小心把東西弄到地上，甚至多數(shù)人還會自覺收拾桌面，那么，結果就是餐廳會減少清潔工的數(shù)量。比如餐廳提倡客人自己收拾，他們就可以招聘更少的清潔工，降低成本。但這對清潔工來說是壞消息啊……
造成開發(fā)和運維矛盾問題的原因可能是多方面的，可能是認識問題，也可能是項目本身的問題(比如交易型網(wǎng)站運維的地位就要比宣傳型網(wǎng)站運維的地位高)。目碰上半夜救火這種事情很多方面的因素都有，
1.比如我程序極限承載能力是 10W 并發(fā)，集群承載能到 20W，但是客戶拿去招投標就說 20W，結果實施方案計劃并沒有涉及集群部署這樣，這是方案留下的隱患問題。當然也存在商業(yè)溝通的問題。
2.比如程序設定的功能 A 很好但是 A 不符合用戶實際使用需求，用戶提了個 A+的功能，然后單純的為了那個+去做定制開發(fā)，為了定制而定制，定制開發(fā)這種事容易出問題我就不多說了……我們后面可能發(fā)現(xiàn) A+確實更貼合實際需求，但是下一個版本乃至大版本更新都沒有把 A+納入基線開發(fā)，還只推出 A 功能，就還會重復做 A+開發(fā)，怕研發(fā)兄弟們工作量不飽和嗎?……這算是產(chǎn)品規(guī)劃方面的問題
3.在開發(fā)過程中吧，確實很多情況現(xiàn)場生產(chǎn)環(huán)境和開發(fā)環(huán)境不一樣(成天聽研發(fā)大兄弟和我訴苦)，尤其是一個產(chǎn)品分了很多模塊，每個模塊又特別細化到單個小組為單位進行開發(fā)，可能真就是自己測試自己的那些功能性能啥問題都沒有，然后一到現(xiàn)場，這個接口不對，那個字段不對……內部溝通也有些問題
4……一時間想不到了。不說了我去補覺了，三點多才睡。
世界上沒有完美的程序，也沒有完美的產(chǎn)品，也沒有完美的人。產(chǎn)品、研發(fā)、交付、運維、商務……都不容易。
對于我們個人來說，我建議找工作的時候，盡量找交易型的，畢竟公司的存在是以系統(tǒng)平臺來賺錢，系統(tǒng)停止就意味著損失，因此個人在組織中的地位自然就比那種宣傳型的網(wǎng)站高了不少。對于認識方面的問題，情況比較復雜，需要做更多的分析和考慮。 回到我們的主題上來。隨便是一個程序員或者測試人員跑過來，就要求干這干那。沒有書面需求文檔，也沒有一個測試反饋流程。這樣次數(shù)多了，運維人員多半就會感覺被支配，不耐煩，疲于應付。第二種情況是：出現(xiàn)故障，先推給運維背鍋。這個真的最要命，也最容易起糾紛。想必不少運維同行也有此遭遇。
盡管我很久沒專注于技術，寫這些文字也有些力不從心，勉為其難拋一些想法，供大伙參考。
▼主動配合
搞技術的人，性格內向的比較普遍，不知道是不是因為長時間跟機器打交道的原因。但不能怎樣，主動與人溝通依然是很重要的工作。我們得告訴其它人，運維實際上在干很多事情(選機房、做系統(tǒng)架構、技術選型、日常維護、半夜爬起來跑機房、24小時響應…此處神略65535字)，要說出來，項目列得越詳細越好!
有些事情在其它人看來(比如開發(fā)人員)似乎很簡單，不就是上架服務器，安裝個系統(tǒng)么?那么我們就要跟他較真：哪個機房帶寬質量好?哪個機房服務到位?怎么裝系統(tǒng)更快、更符合要求(不要給我們講一路回車，一根到底、程序數(shù)據(jù)一鍋端)?做了要說，而且要多說，才能讓別人了解我們其實下了很多功夫，做了很多工作。我時不時會給其它人強調，你們設計的界面在美觀、程序再怎么牛逼，系統(tǒng)崩潰了，僅僅是一堆占據(jù)硬盤空間的二進制而已!就算沒崩潰，找的機房線路垃圾，能跑的起來才是怪事呢!
▼部門協(xié)作
中國人是一個人情社會，只有大家時不時一起吃個飯，很多事情就好商量了。你是否準備請或者被請，跟其它部門的人一起出去吃飯呢?
把責任推給別人，原因很簡單—利益和面子!誰愿意努力付出了，最后卻因為發(fā)生故障扣錢甚至影響前途呢(很多機構只注重處罰而很少提及獎勵)?遇到人品差的，這種情況發(fā)生得就很頻繁了。
沒有人保證系統(tǒng)運行中不發(fā)生問題或故障，除非把電源給關閉掉。我經(jīng)常的措施是：
1、收集相關資源的聯(lián)系方式：機房、供貨商、服務提供商(cdn之類的);
2、收集相關技術人員的聯(lián)系方式：技術負責人、程序員、測試等等;
3、根據(jù)業(yè)務，故障報警發(fā)相關人員;
4、聯(lián)系接口人員告知故障發(fā)生，獲取故障現(xiàn)象并簡單描述
5、要求相關人員協(xié)調排查;
6、告知自己排查的情況(查了哪些項目、數(shù)值是什么狀況、修改了什么、數(shù)據(jù)截圖等);
7、故障排除，總結經(jīng)驗;
8、內部討論一下，看能否大事化小(小事化了要看具體情況)。如果不是己方的責任，過分強調過錯或過失，又會回到相互推卸責任這個老路上來。
▼處置流程
沒有流程，必定會引起一團糟，比如前邊說的，隨便是個人就跑過來提要求;流程太繁瑣，也不行，會嚴重影響效率。在這里，不強調怎么做流程，但起碼，我們可以相互約定一個接口人，有什么需求，盡量通過接口人。
如果什么都不能改變，盡快閃人吧!
作者：田逸 文章來自51cto
以上就是100唯爾(100vr.com)小編為您介紹的關于運維的知識技巧了，學習以上的信息技術：運維跟開發(fā)一定有仇嗎?開發(fā)能在多大程度上幫助運維減輕半夜被叫起的負擔? 知識，對于運維的幫助都是非常大的，這也是新手學習信息技術所需要注意的地方。如果使用100唯爾還有什么問題可以點擊右側人工服務，我們會有專業(yè)的人士來為您解答。
本站在轉載文章時均注明來源出處，轉載目的在于傳遞更多信息，未用于商業(yè)用途。如因本站的文章、圖片等在內容、版權或其它方面存在問題或異議，請與本站聯(lián)系(電話：0592-5551325，郵箱：help@onesoft.com.cn)，本站將作妥善處理。
向客服提問運維課程推薦
信息技術熱門資料
信息技術技術文檔
推薦閱讀
