• <nav id="kcwou"></nav>
  • <menu id="kcwou"><strong id="kcwou"></strong></menu><u id="kcwou"></u>
  •  

    有一種能力叫“運維”

    放大字體  縮小字體 發布日期:2017-10-24  瀏覽次數:1859
    核心提示:這是對一個問題的回應中?。ɑヂ摼W)企業真的需要運維么?很有意思的現象,這個問題的提問者有時候包含了運維人自己。我一直用這樣的回答來回復提問者你可以不需要運維人,

     這是對一個問題的回應——“中?。ɑヂ摼W)企業真的需要運維么?”

    很有意思的現象,這個問題的提問者有時候包含了運維人自己。我一直用這樣的回答來回復提問者“你可以不需要運維人,但不能不需要運維,運維是一種能力,它可以帶來業務價值。

    很多人都是從需求——》研發——》測試——》維護過程來看運維的,中小企業認為自己的IT不復雜,可以不需要測試或者運維,因為根本不知道他們能帶來什么價值?

    這個時候你都是把測試和運維看成某類具體的角色了,你認為可以不招聘相應的人,但是你不能忽略測試和運維的作用。今天不把傳統企業納入范疇,只對互聯網+型公司進行討論。

    從業務的驅動力來說,互聯網+型的業務速度越來越快,版本每日多次迭代。在強調業務驅動力的時候,很多公司看到了業務功能的實現,而忽略基礎能力的構建,從而本應工具解決的問題,最后引入了大量的人來解決,吊詭的是,在軟件領域,人的增多,并不代表生產力的提升。

    也本應在一定的階段,引入工具對IT流程進行優化,此時可以帶來更多的時間和人力成本的節省,但依然忽略了。我認為這是過分強調業務驅動導致的,還有一個技術層的原因。

    說到技術層的原因,我們都知道,隨著業務越來越復雜,產品線會裂變越來越多,此時的組織復雜度就出來了,各個團隊的行為會逐漸變得自主。在團隊規模小的階段,組織內部的信息流依然還是有序的,因為是少量人控制,可以通過面對面溝通解決。但在很短的時間內,產品迅速增多,信息流變得無序了,出現無規范/無制度/無平臺的狀態。技術層的原因,離散組織缺少中心控制節點。

    那針對以上問題,測試/運維到底能起到什么樣的作用呢?

    強調業務驅動沒有錯的,但過分強調業務驅動則有錯,沒考慮業務驅動背后的其他因素。其實測試和運維也在強調業務驅動,但和研發所focus的業務驅動有很大的差別。

    研發強調的是業務上的功能實現,而測試運維分別強調更好的功能實現,什么是更好?如功能可測試性,功能的完備性,可維護性,穩定性等等。從專業分工的角度來說,測試和運維長期了以來形成了大量的方法論用于支撐軟件研發的過程,確保高質量交付,不應該忽視長期形成的經驗。

    強調測試/運維的早期參與,是一種測試/運維驅動研發的軟件方法論。舉個簡單的例子,測試在早期不參與研發需求評審的話,測試只能成為研發的附屬過程,研發交給你什么,你測試什么,此時它就是一個成本中心,而不是價值中心,對于運維來說也是如此??蓽y試性和可運維性可以對軟件的設計提出很多合理的要求,從代碼的可測試性到整體架構的可運維性等等。

    回到技術層面上——離散組織缺少中心控制節點。為什么運維可以成為中心控制節點?成為中心控制節點的運維到底還能做什么?接下來就是其他的組織設置和流程設置的問題了。

    為什么運維可以稱為中心控制節點?從交付鏈條來說,所有的服務交付都最終到運維這邊,運維離用戶最近,能夠第一時間獲取服務的用戶使用狀態;其次生產環境的集中管理一定是運維來保證的,運維能夠建立起統一的技術管理規范。

    針對第一點,運維及時的獲取服務狀態及后續的服務狀態更新之后,可以去反向驅動研發進一步的服務優化,這個優化有業務上(體驗及服務),也有非業務上(性能及成本)等等,這是運維的驅動力。

    針對第二點,這是運維的核心控制力,建立起統一的技術標準規范,在公司內所有產品線統一推行,讓大家方向一致,減少混亂帶來的無謂消耗,這是運維的控制力。

    此時需要做一些變化,把運維的職能從研發里面剝離出來,建立一個統一的中心化運維組織。我把DO關系分成三個階段,

    • 第一個階段:DO混合,大家的職能交織在一起,運維是研發的附屬過程,運維的職責就是資源交付;
    • 第二個階段:DO分離,研發和運維走向分離,一些維護的壓力逐漸浮現出來,專業的運維如何更好的做好運維,定規范,建平臺,收數據等等;
    • 第三個階段:DO融合,注意不是混合。融合是指一種能力的流動,運維的能力已經是研發過程自然而然考慮的一部分的了,另外這種運維的能力隨著平臺/規范/流程的完善,此時研發都可以具備真正的運維能力。

    成為中心節點的運維到底還能做什么?其實能做的事情就很多了,定規范/建平臺/收數據等等。規范可以分多種,線上運維的規范,持續交付過程規范,涉及環境管理/流程規范等等,還有安全規范,事務驅動的規范(可用性驅動研發)等等,很多很多。

    平臺里面涉及到自動化平臺,覆蓋各種運維場景,可以是工具化的運維場景,一些配置管理工具就能解決的;還有一些復雜的業務場景,這個需要專業化的運維管理平臺來完成的等等;數據驅動運維,驅動DevOps,需要采集大量的技術運營數據,這個地方有一個爭議,運維是否要覆蓋產品運營的數據分析場景?我倒不建議,聚焦在自己擅長的部分,當然可以不阻止這個想象力,注意監控平臺可以理解成數據體系的一部分。

    最終通過平臺來沉淀規范,能力通過平臺來表達,從而實現運維就是一種能力。基于能力的運維交付,才是真正的運維。

    最后我想說,有一種能力叫 運維,而不是有一類人叫運維,對于中小企業甚至是初創企業,你可以不要運維人,但你不能不要運維的能力,因為它可以讓公司更好,業務發展更快,為什么不呢。不知道你怎么看呢?

     
     
    [ 產業搜索 ]  [ 加入收藏 ]  [ 告訴好友 ]  [ 打印本文 ]  [ 違規舉報 ]  [ 關閉窗口 ]

     
    0條 [查看全部]  相關評論

    推薦圖文
    推薦產業
    點擊排行
     
    首页中文字幕中文字幕