敏捷與DevOps

敏捷在疫情中，為企業帶來了什麼實質的影響? 從麥肯錫2的兩項調查統計來看 在客戶滿意度、員工參與度、與營運績效來看，在同一企業內，敏捷程度較高的部門表現顯然優於敏捷程度較低的部門。 基於亞洲與歐洲電信運營商的組織應變速度來看，敏捷成熟度最高的組織較成熟度最低的組織有著近兩倍的差異。 不可諱言地在疫情前，轉變對於組織來說，並不必然是極為迫切的事情。因為市場變化雖然強勁，但壓迫力卻並非立即性地逼得企業喘不過氣來。疫情來臨時，交付管道的失效、聯繫方式的失效、工作空間的失效等等問題，讓供需兩方彼此交互增強對於變動的需求。敏捷基本上是想找尋一個系統性的方式來解決最終結果的不確定性。畢竟，商業環境唯一不變的真理就是改變。 從疫情中過渡到後疫情 對於組織來說，什麼才是所謂「系統性」的方式? 這就得同時從團隊層級與企業層級兩個不同層級來探討，畢竟敏捷並不是組織內某個單位的事情，而所謂的文化改變，也不可能忽略組織的營運與治理。但不管哪一個層級，以敏捷的角度來看有兩件事是重要的： 1. 貼近於現實的可調適能力； 2. 可視性。 透過看板、電子協作工具，以及基於上述工具的指標儀板，組織才能在霧濛濛的不確定性市場中具備視覺能力。有了這些視覺能力，組織才能夠以更為全面的視角，客觀地衡量現況，進而調整自己的步伐。具備了這項基礎的能力後，才能讓調整步伐的能力有效展現。這就會回到了「如何實際地讓自己具有貼近於現實的可調適能力」這件事上。具體作法不外乎是 企業層級能夠盡快響應市場變化，調整方針與重要項目；團隊層級能夠基於這些改變的方針與實際場景的差異，具體地進行微調，來達成目標。 為了能夠做到這些事情，企業必須要思考的不會是如何帶入別人成功的套路，而是要去反思當前的營運模式、流程與治理方法。 企業作為一個法人，正如同自然人一般。面對外部刺激的反應，可以從大腦下達指令，然後產生相關反應，也可以在一些「特定條件」下，「授權」各部位直接採取行動。不管是從大腦下達，抑或是特定條件下的授權行為，為了能夠更有效率且無誤地發生效果。需要的不只是應急措施，更重要的是能夠重複的「成功規則」。因此，在得益於敏捷的實務作法，而在此次疫情中獲益的組織，在疫情之後，應該要去思考的是： 1. 疫情中採取了哪些應該持續下去的改變，還有哪些問題並未被解決； 2. 匯整經驗，融入日常營運，並且強化與擴大這些經驗的成熟度與覆蓋度。 後記 敏捷不僅是一種方法，也是一種能力。面對疫情所帶來的紛亂，提升企業的敏捷能力，便是提升企業韌性的最好策略。 1. Photo by Elena Mozhvilo on Unsplash 2.

前言 隨著企業提升響應市場變化的速度，不管企業的規模為何，抑或屬於哪一種產業，DevOps 儼然成為現代 IT 的重要典範。但在快速迭代的業務發展下，由於傳統的安全治理較為繁瑣，也使企業在導入 DevOps 的過程中，從需求、設計、實作，到後續的監控和改善，較難看見充分的安全實踐，組織亦缺乏在每個流程階段，衡量當前安全的成熟狀況。 什麼是 OWASP DSOMM？ DSOMM 2 的全名為 DevSecOps Maturity Model（DevSecOps 成熟度模型），或許大家較耳熟能詳 OWASP 的另一個軟體安全的成熟度模型 SAMM（Software Assurance Maturity Model，軟體保證成熟度模型），SAMM 針對五個業務功能（治理、設計、實作、驗證、維運）定義了一系列的安全實踐及評量指標，協助組織將安全覆蓋至全軟體開發生命週期。SAMM 為較高層級的規範性模型，而 DSOMM 則為更具體的 DevSecOps 實踐。

在過去帶領 DevOps 團隊的經驗裡，有時會遇到團隊成員對於身為 DevOps 工程師的價值有所疑惑或迷思： 🤔 我們好像只是在做各種工具的整合…是不是要像開發人員一樣寫程式，這樣才比較厲害！？ 🤔 是不是要像開發團隊一樣面對市場客戶的需求，這樣才能產生價值的交付？ 🤔 是不是打造完工具鏈，DevOps 團隊就不需要存在了？ 本文同步刊登於 DZone - Addressing Concerns About Being a DevOps Engineer 認真做好每一樣事物，這才是工程 在工程的世界裡，每個領域絕對都有它專業價值的存在，只是使用的技術、工具及面對的客群不同。雖然各種 IaC 或 XaC 的工具，不像廣為人知的 Java、TypeScript、Python 等程式語言，但在撰寫的過程中，仍然需要基於邏輯地去考量彈性度、模組化等，以及如何透過測試維持品質。有時更因為它是基礎設施或與合規相關，所以相顯之下它所衝擊的範圍也較為龐大，而需更加謹慎。且在五花八門的工具世界裡，選擇一個適合您組織文化、流程、團隊技術線的解決方案，也是個大哉問，不落入貨物崇拜尤為重要。因此，只要保持好奇心、積極的態度，把事情做對，不論背後所採用的技術為何，這就是工程的美妙。

安全的運行環境對於雲端服務來說，是個重要的議題，而對於使用者來說更為重要。 因此，對實體或虛擬主機進行弱點檢查與監測，能為雲端服務提供一個安全的基礎，也能滿足組織對於資安的基本要求。然而，安全威脅多樣，且各式作業系統的組態設定又各有巧妙，要如何才能有效率地完成這個工作，對於維運人員來說是相當令人頭疼的事情。 SCAP2 (Security Content Automation Protocol) 是由美國國家標準暨技術研究院(National Institute of Standards and Technology, NIST3)所維護與制定的協定，主要用意是為主機的組態設定與安全需求提供一個共同交互與發展的基礎。同時也為 NIST 800-53 關於運行主機的安全要求與最佳實踐提供一個自動化的基礎。 OpenScap4 則是基於 SCAP 的具體實作，它主要透過使用 SCAP 裡的 XCCDF5(Extensible Configuration Checklist Description)與 OVAL6(Open Vulnerability and Assessment Language)。XCCDF 透過 XML 形式的描述語言具體地提供評估與檢查一個主機時，應該進行的項目列表。測項可能是一些安全需求下的組態設定的檢查，也可能來自 OVAL 所識別的弱點測試。