有沒有一個餓鬼占領了你的Kubernetes環境?如何與章魚掃描儀背後的聰明對手決鬥?也許您覺得有必要將舊的、頑固的CI/CD實踐比作飛猴綠野仙蹤．無論您是否與這些令人毛骨悚然的DevOps故事有關，肯定都可以從每個故事中學到一些東西。圍坐在篝火旁，準備好迎接恐慌吧。
在這個DevOps的圓桌會議由DevOps.com(現為Techstrong Group)首席執行官兼主編Alan Shimel主持米奇·阿什利他是Accelerated Strategies Group(現為Techstrong Group)的首席執行官，Alexander Sascha Mohr，Tricentis的產品經理，Parag Doshi博士他是Tricentis的工程副總裁，特蕾西Ragan他是DeployHub的首席執行官兼聯合創始人，茉莉花詹姆斯Twitter的工程經理，以及德裏克。周Linux基金會的高級副總裁兼首席營銷官，以及All Day DevOps的聯合創始人，他們分享了他們最可怕的DevOps測試經驗和教訓。
觀看下麵的完整視頻。
在找鳳凰計劃的布倫特
[Mitch, 07:46]它始於我進入DevOps的旅程，大約在2013年左右。艾倫，你跟我說過DevOps這個東西，所以我重新讀了一遍鳳凰計劃。我想，這太棒了，讓我們看看我們能做什麼。我們在工作的時候和我管理的IT小組一起辦了一個讀書俱樂部，我說，讓我們一起讀這個吧。但發生的一件事是，他們突然開始濫用萬聖節的主題，對我們組中的“布倫特”進行政治迫害。如果你還記得的話，布倫特來自鳳凰計劃是所有事情的瓶頸。我們想知道，布倫特是誰?我們發現我們都有一點布倫特的影子，以我們自己的方式。
從未存在過的考試中心
薩沙[10:47]我最喜歡的一個故事來自大約一年半前與一位客戶的討論。他們正在進行數字化轉型，我們討論了實施卓越測試中心(TCoE)。當你想到卓越的測試中心時，通常你可以把它想象成一個汽車製造商或生產線，當你得到所有的零件，比如發動機，變速箱和底盤。您需要將所有這些組合在一起，然後驗證您正在構建的東西是否真的如預期的那樣工作。然後，當我們談論DevOps時，問題總是;卓越測試中心是否適合DevOps世界，或者我們應該取消它?這讓我大開眼界，因為客戶說:“我們認為我們需要一個測試中心，但我們的管理層正計劃完全減少這個中心。”他們的願景是我們不需要測試中心，團隊應該做所有的事情。一年後，當我們檢查客戶時，他們沒有測試，也沒有任何類型的治理。他們基本上說:“這對我們來說行不通。” And that’s what we currently see when it comes to testing. Testing is not just what the team is doing, but it’s always around the collaboration and the end-to-end test validation across the pipelines and across the application landscapes.
不要讓舊習慣難以改掉
[13:21]我稱自己為“文化轉型的壞女巫”。有趣的是，文化轉型是第一位的指的是早些時候的一項民意調查，50%的受訪者表示“文化”是他們組織中與DevOps相關的最麻煩的領域]因為這就是我故事的來源。我還把它命名為“獅子和老虎與文化轉型，哦，天哪!”所以當你想到壞女巫的時候，在綠野仙蹤故事，是的，這就是我。回想起我在多家公司工作過的時光，我認為這是最難說清楚的事情之一——尤其是在大公司裏。我不僅領導了支持DevOps的工具的工具工作，而且還領導了我們如何在團隊中提升技能和創建DevOps文化。這對人們來說是最麻煩的一次跳躍。當我在一家大型航空公司工作時，我們看到了很多增長，其中一件事就是那些舊習慣反複出現。要打破與CI/CD實踐相關的舊習慣是非常困難的——你知道，代碼質量，那些性質的東西，尤其是如果它們以前不存在的話。我把它比作在《綠野仙蹤》中襲擊多蘿西和她的團隊的飛猴。它們不斷地出現——那些舊習慣。引誘團隊回到他們原來的方式。所以謝天謝地，我們能夠創造持續的適應，與團隊一起創造價值，並在他們所在的地方滿足他們。正是這一點幫助我們在團隊內部推動文化采納和DevOps實踐，從而避免回到舊世界。
[艾倫]我們如何克服高度受監管驅動的文化挑戰，比如銀行業?
在外麵保持安全
[15:53]我認為我們有最多的監管是關於隱私和數據的。但我認為文化挑戰無處不在。我認為這需要團隊的韌勁來推動這種文化的采用，並確保他們在團隊內部和領導層之間建立理解——做這些事情的好處是什麼，而不是僅僅“因為”而做。我們必須了解它的價值。然後把它和安全聯係起來。一想到監管，就會想到安全問題。我們如何利用一些DevOps工具標準來在受監管的行業中提高安全性呢?
讓首席信息官成為你的朋友，而不是敵人
Parag[17:08]說到受監管的行業，除了金融服務，另一個是醫療保健。其中一個故事與這種文化轉變有關。即使在醫療保健行業，我們也看到了這是個問題，因為我可以告訴你一個可怕的故事，我們的醫療保險會員門戶網站有一天宕機了，所有高管的第一反應是，這是怎麼回事?讓我們盡快解決這個問題。這是怎麼發生的?誰泄露了這個缺陷?相反，工程團隊所做的是，在幾秒鍾內，重新部署了整個站點，這在一年前是聞所未聞的。這個工程團隊優先考慮恢複，而不是在生產中永遠沒有缺陷這一不可能的挑戰。這本來就不可能發生。假設事情會在你發布產品時發生。 And if you can prioritize how quickly you can recover over having a 0% defect leakage rate, I think that can go a long way. The second point, I’d say, in regulated industries, is, as Jasmine correctly pointed out, it’s about security, data privacy. Here, culturally, one of the most important factors that I found is to make the CISO, the Chief Information Security Officer, your best friend. I was a VP of cloud, but if I did not have my CISO on my side, who also saw the vision, we would have been hopeless. And so we work together to build out a security roadmap and tie in all the necessary security controls before we even ever considered putting protected information into, or even talked about putting that into, a public cloud.
小心微服務的蔓延
特蕾西[22:34]嗯，我把這個故事叫做餓鬼故事。這恰好發生在我們決定麵向對象編程將成為發展方向的時候。這也是在OS2前後。當你為OS2構建應用程序時，OS2有一些特殊的事情發生。這是關於SOAR 3030.DLL的故事。這是一家擁有嚴格審計流程的金融公司。因為它是OS2，當你加載一個DLL到內存中，如果它已經在那裏，它不會重新加載它。通常當人們去做一個標準錯誤時，這個SOAR 3030就是一個標準錯誤程序，所有的團隊都被要求使用同一個錯誤程序。但是我們會遇到陷阱，我們過去稱為OS2的可怕的墓碑會出現，而且它會在事務中。在與客戶一起工作的過程中，有一個錯誤例程，它會調用SOAR 3030，它會創建一個墓碑，我當時會調用它。 And I was given the task to go find out what happened. So I decided to just do a search on all of the servers throughout this entire organization which had literally thousands of servers for SOAR 3030.DLL. And I piped it to the printer, thinking I’d get a page. And I went home. The next day, I went to the printer in the hall, and it had stopped. And I was like, hmm, that’s interesting. It stopped and I looked at what had printed out, and it was a pile.
當我深入研究時，我意識到每個應用程序團隊都在從他們自己的存儲庫編譯共享庫，這意味著他們有自己的版本，並且沒有重命名它們。現在業界決定變得非常聰明，解決這個問題，不是通過解決make步驟，這實際上會容易得多，而是他們決定重命名這些庫。所以現在，不再有一個中心來解決問題，你必須解決每個版本。現在，我之所以提出關於SOAR 3030的故事，是因為我們正在進入與微服務完全相同的情況。微服務，如果它們被正確實現，應該是高度重用的，應該隻有一個常見的錯誤例程。所以如果你需要為組織修複它，你就修複它，把它推回你的Kubernetes集群，這取決於你的Kubernetes部署文件是如何定義的，每個人都應該接受它。類似於我們的醫療保健情況，如果我們在Kubernetes集群中出現勒索軟件問題，我們應該能夠在一個地方修複它，每個人都能得到修複。所以不要讓一個饑餓的幽靈接管你的Kubernetes環境，因為那被稱為蔓延。在我的例子中，在麵向對象的時代，我們有一個單一函數的擴展。這就是微服務的可怕之處和複雜性。
章魚掃描器vs開源
德裏克[38:35]我有一個“不給糖就搗蛋”的故事。從款待開始。我花了很多時間研究高性能軟件開發組織、軟件供應鏈、開源使用和軟件開發。在軟件開發中大量使用開源，是DevOps在開發中更快發展的一部分。沒有人需要從頭開始編寫所有的代碼，你可以在幾秒鍾內從互聯網上下載一些代碼，免費使用，這讓你移動得更快。大約80%的應用程序都是內置的開源二進製文件或開源包。自2018年以來，我看到與開源相關的入侵數量逐年下降。他們已經從大約30%的組織變成了大約20%的組織，我認為這在很大程度上與equifax被泄露的情況有關。人們說，我不想成為下一個Equifax，所以他們進行了投資。但這其中的技巧，或管道中的目標是，對手知道組織正在尋找已知的易受攻擊的開源組件。 So the adversaries have shifted tactics in the last few years to look at how to inject malicious code into the actual project and then have it downloaded by 1,000, 10,000, 100,000 people a week… We saw about 1,000 instances of those open-source project-based attacks last year, but the real kind of head scratcher that we saw was this vulnerability called Octopus Scanner. And it was discovered by GitHub researchers, and what this did was it started to modify the NetBeans IDE that developers were using, and the NetBeans IDE would inject malicious payloads into any jar that was being built in the IDE. So they’d just go to the developer tools themselves, inject malicious code into anything that they’re building. So the known vulnerable pipelines are the easiest to find the maliciously injected code, whereas at the beginning of a supply chain it’s a lot more difficult, if not impossible to identify.