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

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

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

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

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

自動化要注意的

1. 不要隨便『自動化』 -> 爛的 Coder 會帶來更多問題、更多職缺，更多 QA 職缺
   • 類似的經驗分享: 軟體自動化測試常見的問題
2. “自動化的程式” 也是 程式，請用 軟體工程 方法面對他，不是能動就好
   • 更多請參考 Software Development Lifecycle, 或者讀讀 SRE 這本書
   • 想想 自動化 的 需求 從哪來？
3. Make Configurable
   • 一言難盡 ….. 相關經歷與設計：Designing Test Architecture and Framework、軟體自動化測試常見的問題, Software QA 的職能條件, 怎樣的 CI/CD 才夠 Quality?、Artifacts Management
4. 那段 “自動化” 在團隊裡不能只有一個人知道他是做啥的
   • 寫自動化程式是一回事
   • 自動化程式的驗證是一回事
   • 自動化程式的重用（可配置性）是一回事
   • 一次跑一堆自動化程式，同時重新配置這些程式，又是另一回事。
   • 參閱: 軟體自動化測試常見的問題、Software Development Lifecycle、Designing Test Architecture and Framework
5. 如果 “自動化” 失效了， SOP 是什麼？平常該怎麼訓練？
   • 自動化可以是軟體測試的自動化，也可以是上線後維運的自動化
   • 那你應該讀讀 SRE 這本書，參考我的筆記： Study Notes - SRE Opening and Chapter 1
   • 參閱：What is Automation?

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

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

自動化？

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

• 品質參差不齊，慘得很慘，特別是人走了之後。
• CI/CD 是程式的 pipeline 串接自動化：
  • CI/CD 過程也用 Code 產生，這些 Code 能測？怎麼測？怎麼 UT? 可以 C/D can self test？能進 git？
  • pipeline 的程序問題：『怎麼測這段程序？程序中的斷點怎麼找問題？機器掛了還能跑？換個人之後還能動？』
  • 相關文章：導入 CI/CD 的第一步、怎樣的 CI/CD 才夠 Quality?
  • 解決方法：Artifacts Management
• 這些問題在做 災難還原 (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

自動化的本質

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

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

• 中國電商污染，5 千萬噸垃圾誰來買單: 電商把人類買賣自動化，背後承擔的是地球。
• 智慧型手機十年進化史，有一些事情必須要知道: 人類為了方便而發明的科技，方便轉化的形式，就是製造一堆垃圾。

自動化是好？我認為，只對一半。

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

延伸閱讀

軟體測試

• What is Automation?
• 自動化 XXX 的陷阱
• 軟體自動化測試常見的問題
• Software Development Lifecycle
• Software QA 的職能條件
• Designing Test Architecture and Framework

CI / CD / DevOps

• Study Notes - SRE Opening and Chapter 1
• What is Ops?
• 警急事件 (Emergency Response)
• 導入 CI/CD 的第一步
• 怎樣的 CI/CD 才夠 Quality?
• Artifacts Management
• Ops as Code using Serverless
• 淺談系統監控與 CloudWatch 的應用

參考資料

• 樂團的經營
• 樂團的主唱