自動化帶來的問題


現在啥都要 自動化ZYX as Code,實際上,我覺得做了這些之後問題才剛開始。整理跟朋友聊天的想法,因為我對 自動化 這個詞其實很感冒。。。表面上是一種先進的方法,但實際上卻是一種駝鳥心態。


你的 “自動化程式” 有可維護性?可配置性 (Configurable)?

對我來說,只要是 “程式” 就盡可能照 規矩 來,什麼叫做 規矩

  • 規矩就是: 要有 規劃 -> 開發 -> 測試 -> 維運
  • 掉書袋的說法: 軟體工程
  • 潮一點的說法: 要有看板、Scrum、看見浪費、看見全局
  • 務實的說法: 當你的信用卡要報失時,打電話給客服,客服可以馬上幫你停卡。換位思考,你的系統做得到?
    • 你的後台可以讓 Help Desk 做幾個動作就完成?還是要找 Develoepr 把忙進 DB 改?
    • 你知道 Help Desk 對這些是很無奈?
    • 你知道你家的 QA 無法重現問題很悶嗎?
    • 你知道你家的 RD 幫 Help Desk 做完後,覺得不知道自己的貢獻在哪嗎?
    • 身為主管的你,只知道報數字,卻不知道數字背後的故事是什麼?

如果你的程式指是 “能動就上” 的層次,建議不要浪費時間了。

自動化要注意的

  1. 不要隨便『自動化』 -> 爛的 Coder 會帶來更多問題、更多職缺,更多 QA 職缺
  2. “自動化的程式” 也是 程式,請用 軟體工程 方法面對他,不是能動就好
  3. Make Configurable
  4. 那段 “自動化” 在團隊裡不能只有一個人知道他是做啥的
  5. 如果 “自動化” 失效了, SOP 是什麼?平常該怎麼訓練?

如果換了人,這些 程式 還能動,那就沒問題。

底下這張圖來自 Coding Explained in 25 Profound Comics #21: When you want to automate everything,大概就是在說我想表達的意思:

When you want to automate everything

自動化?

實務上 “自動化” 要面對一些問題:

  • 品質參差不齊,慘得很慘,特別是人走了之後。
  • CI/CD 是程式的 pipeline 串接自動化:
  • 這些問題在做 災難還原 (Disaster Recovery, DR) 全都會浮上檯面,因為像 Jenkins 這種 Plugin 依賴很深、Config 結構很亂的工具,就是問題的源頭。
    • 因為 Jenkins 本身的 Job 沒有可測性,除非使用後來的 Pipeline 把這段流程都放到 git.

恩,一些想法,因為我對 “自動化” 這個詞其實很感冒。。。感冒的源頭請參考: 軟體自動化測試常見的問題,因為本質上是一樣的。

嚴格講,把程序變成程式這件事情,不等於自動化。 那自動化是什麼?,請參閱: What is Automation?, 自動化 XXX 的陷阱
我想表達的是『本質性』的探討,更多參閱:思考本質、實踐、想像力、教育

NoOps? AIOps?

這兩個東西我只有以下 Question:

  • 出了問題,需要處理,誰處理? Nobody or AI?怎麼處理?
  • AI 誤判可以接受?那就 AI / ML 吧。
  • Automation 出了問題可以接受?可以承擔損失?那就 Auto 吧。
  • Automation 之後,還有人知道 Manual 怎麼做?如果 Automation 故障了,只能攤手?
    • 現在的飛機飛航很多都是自動的,但發生事故時,還是會切回手動。這時候機師跟你說,我不會手動。。。
    • 更多參閱 SRE 的 警急事件 (Emergency Response) 的討論。
  • 誰來 Ops NoOps or AIOps ?
  • What is Ops?, Ops as Code using Serverless

2018/07/02: GCP用戶抱怨服務遭無預警關閉,緊急搶救後仍有一小時的資料無法救回
2018/07/17: 沒谷歌不行.. 當機造成寶可夢、Snapchat暫時下線

因噎廢食? (2018/05/02 補充)

只要說到自動化,一些主管、老闆、管理者、局外人就想開始幻想、腦補,然後開始找了一堆工具、或者看了某一些文章、書本寫 自動化 XXX (XXX 請自行帶入測試、監控、維運 …) 之後,從此就能如何如何,人力就可以節省多少。恩。。。說真的:『很傻,很天真』,真的想得太簡單了。

自動化不是萬靈丹、也不是黑魔法,請先認清楚她必要的前提與背景。

自動化的前提要有程序正義,能夠清楚定義情境各式各樣的程序、SOP、應用場景,要有相對成熟的技術掌握力、軟體工程能力,最重要的是,能夠 持續改善 自動化程式本身。否則大部分的自動化程式我認為都是場災難,不是要唱雖,而是路遙知馬力,換個人就知道是否成功。

然後,我不是反對『自動化』這件事,但 強烈 反對以下:

  • 為了自動而自動
  • 不做好基礎功,只想一步登天
  • 不想面對自動化背後的問題,與代價
  • 用行銷來包裝自動化,像是 AI / ML,而忽略現場的問題

大部分的自動化程式

自動化 很吃基本功,特別是配置管理、本身的品質、AM … etc,所以這麼多年觀察到的現象:

大部分的自動化,大概都是以下這張圖:

What is Team Work?

以前玩 樂團的經驗 就是:歌曲進行中,有人出狀況了,不管是鼓手、吉他、Keyboard、Bass or Vocal 有狀況,都有人可以自動遞補上去,然後進行中的歌曲還是可以繼續走,完成表演。

This is Team Work. 團隊要能自動化 - 互相 Cover,彼此持續改善

團隊協作能做到自主性,才是 真.自動化! <– 這就是 行銷包裝 術語,寫文章就是要寫這種東西 XDD


自動化的本質

能量不滅,自動化只是把事換成另一個形式,然後人們就忘記他。 這就是我說的鴕鳥心態。

底下是商業自動化之後帶來的問題:

自動化是好?我認為,只對一半。

這幾篇整理一些看法: What is Automation?, 自動化 XXX 的陷阱, 警急事件 (Emergency Response)


延伸閱讀

軟體測試

CI / CD / DevOps

參考資料



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲