上上週在一個 公開的演講 (Monitoring) 之後，去搭捷運時遇到一個陌生朋友，走過來跟我握手，說他聽了我某次的 演講之後 (Ops as Code) ，很有感，講到他遭遇的問題、處境，這次他又特別來聽我講，我心想：大概就是遇到同溫層吧，我只是把那些問題點出來而已～很高興他的 Feedback，讓我又更確認這些問題不是只有我一個人遇到。

再思考：『維、運』或『運、維』

其實那場我是把這幾年的經驗作匯集跟分享，技術反倒是講很少。其中的精神就在探討 維運 的本質，之後衍伸了探討 什麼是監控？、什麼是自動化？ 等課題。

什麼是維運 (What is Ops) ？ 這個問題這幾年在我心裡至少問過自己數千次、數萬次，問到都開始懷疑我的人生了。。。

看了一堆東西、高大上的書、傳統的書、面對實際問題處理的過程，最後在兩年前 (2016) 準備 認證考試時 整理出來就是這樣：

• 運 (Operation)：一句話來說『所有 IT 資源的 生命週期、制度流程』
  • 像是制度、流程、方法、生命週期
  • 預算、決策 … 等
  • 組織、權責
  • 事件管理：包含異常分析、緊急事件處理、事後追蹤
  • 通報機制、預警機制
• 維 (Maintain)：目的導向，像是
  • 監控：告警、儀表板、觀測
  • 效能：資料庫效能、儲存效能、容量規劃
  • 網路：DNS、Gateway、Switch、Router …
  • 維護：系統升級、備份還原
  • 資安：SSL、帳號權限管理、Key 管理
  • 儲存：儲存設備管理、Log 分析
  • 打雜：定義作業程序、作業規範
  • 其中『監控』只是其中一項比較被看得到的而已，它包含了『監』、『控』兩個面向。

這兩個一般慣稱 O & M，對岸稱『運、維』

這兩個可以橫跨 企業管理、產品維運 兩大範疇。

2018/06/22 補充：「營運」> 「運維」，前者是整個公司的「營運」狀況，是整體財務面向，頭是 COO；「運維」通常是 IT 的範籌，頭是 CIO

『企業營運』跟『產品維運』是兩種 Operations ，如下圖，更多說明詳細參閱 2019/04 分享的 導讀持續交付 2.0 - 談當代軟體交付之虛實融合

抱怨 - 負能量

這些東西，沒有深入思考過、沒有做過，真的不會有感覺，也不會有痛點，因為：

• 你的痛跟我沒關係
• 你的事，干我屁事
• 監控不就是看到問題再處理就好？
• 不是自動化就好？
• 這些跟商業無關啊？
• 不要再無病呻吟了

特別是這些的付出都是屬於成本性質，會被重視的機率又更少了。

這跟從沒做過自動化測試的人，整天在那邊喊要自動化有啥好處，但是卻不提『前提』必要條件一樣，高大上、出一張嘴，做過才知道痛在哪。跟工具沒關係，跟制度流程有關係。為啥我會知道，因為看到好工具被亂用就覺得很囧，看到歷史一再重演，都很想殺進去救他們。。。

那場演講中，我直接說明了：

Ops 在大部分的企業裡就是『成本單位』，所以不會有公司投入資源的，通常『公司治理』的雜事要做，『產品維運』的要做，所以傳統的 Ops 人都有 極度 SOP 化 的特質，換言之：很難要他們主動。

現在因為 DevOps 流行，所以書都寫得很好聽，叫做：稀缺資源，直白的話： 你是這家公司的員工？。。。但我看了大部分的書寫的範疇還是只有在 產品開發 而已，實際 Ops 要面對的不會只有『產品開發』的維運，還包含 公司治理 的 IT / Infrastructure，九成九的 MIS / OP 角色，都需要同時跨這兩塊，但是，管理階層九成九當作一件事來看，反正沒人做的，就丟過去。

通常這範圍太大，很容易被忽略。。。想到上次一位朋友說：

對 Ops 的職涯感到很沒希望

會說這樣的話，其實不意外。

領悟 幹話 大全

怨念很深，所以領悟了一些事與想法。。。看看就好 XDD

這只是一點點點的怨念 XD

大忌

如果想要 Dev & Ops 能合作、協作，或者讓團隊能獨立自主，千萬、千萬、不要說：

• NoOps：這是 侵入式 說法，會直接製造敵對狀態、摧毀信任
  • 想要改變或者省略原本的位置，要透過 Migration 方式移轉，不是直接移轉，一定出事
  • 職責的移轉，或者改變也是
• 自己開發自己維運：這是 強加式 的說法，會讓團隊心情的浮動、模糊定位
  • 除非團隊成員夠成熟，成熟包含軟、硬技能條件都充足。
  • 摧毀 R&R = 摧毀信任 = 不會有產能 = 倒閉
  • 不清楚的 R&R = 招募不到適合的人 = 招募到很貴，但不適合的人
• 這些跟商業無關啊？，大忌中的大忌
  • 依照這句話的邏輯：幹嘛花時間做？那我就不要做給你看！直接肅立敵對關係，馬上開 104
  • 已經整天在幫開發端擦屁股了，聽到這樣的話你覺得會舒服？
• 附帶一提：也不要輕易說出 NoQA、NoPM 這種話 … 會製造對立與不信任感
  • 說出這種話，某種程度也凸顯自己的無知
  • 凸顯只想強加一些想法，跟共產黨一樣

上述這兩種，會直接或間接摧毀團隊對於管理階層的信任與對立。

幾個前提一定要知道，要溝通：

• 維運是有技能性、專業度：不是阿貓阿狗都可以做得來，關鍵字有 系統工程、維運、SysAdmin、DevOps、SRE、Infra as Code .. 等
• 團隊的協作，需要時間發酵的、有人推動的
• 監控的技術是高度專業的

當 信任 已經被摧毀，接下來什麼事都推不動了。

聆聽

• 聽聽團隊的聲音，聽聽他們面對的問題。
• 不要多說什麼，不要急著分享自己的想法
• 沒搞清楚狀況之前的建議，都只是 noise
• 解決團隊現場的問題
• 不要有官階，不要說我以前如何如何。。。不要說你應該如何如何。。。

聆聽、傾聽、幫助、信任。

正能量 - 改變

這幾年在 Ops 這一塊打滾幾圈，不管在工作上、還是在外面社群，發現這個問題幾乎在每個公司都有，除非大主管本身是 Ops、SRE 出身，否則問題都差不多。我一直在思考這件事情應該怎麼改變，團隊該怎麼面對？

以下這段話是我寫在 Facebook 上的一段話，用來勉勵自己，也送給讀者：

雞蛋，從外打破是食物，從內打破是生命。等待別人從外打破你，那麼你注定成為別人的食物；自己從內部打破，那將會獲得重生。

人生外來的是壓力，自己從裡面打破的將是成長。每次跌倒，都是成長的機會，每次站起來，都讓你用來越強壯。

團隊，內部的改變是成長，外部的改變是壓力。

茶葉蛋蛋殼破碎最多的，最入味。蛋殼的碎裂，代表人生的歷練、經驗、故事，因為這些，所以人生更入味。

希望這些可以給我自己，或者來這裡的讀者一些正能量。

團隊的養成 - Dev & Ops 的合作

麵粉加入酵母發酵，要時間不斷的揉麵
麵包烤出來才會好吃，然後留下一點老麵，繼續傳承

團隊需要 時間 的 發酵，有人持續 推動
然後 老麵 持續 傳承、有 溫度 的傳承

延伸閱讀

• Ops as Code using Serverless
• What is Ops?
• 自動化測試常見的問題
• 系統維運的精神
• Monitoring Tools 大亂鬥 - AWS CloudWatch
• 警急事件 (Emergency Response)
• 思考本質、實踐、抽象、想像力、教育
• What is Automation?
• What is Monitoring?
• 系統維運的精神
• AWS Certified SysOps Administrator - 準備心得
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合