在這期DevOps Unbound中，Alan Shimel和來自蜂巢的Christine Yen, Tricentis的Paul Bruce以及來自ASG/MediaOps的Mitch Ashley一起討論了如何有效地測試你的應用程序的性能，以及如何將可觀察性引入其中測試環境可以幫助DevOps團隊在SDLC早期識別和解決問題。下麵是視頻，下麵是對話的文字記錄。
阿蘭Shimel:嘿,每一個人。我是Alan Shimel, MediaOps的CEO, DevOps.com的主編，Security Boulevard, Container Journal，您正在收看的是DevOps Unbound。DevOps Unbound是一個兩周一次的視頻係列，在這個係列中，我們邀請了社區中的一些重要人物討論DevOps相關的話題。我們非常幸運地得到了Tricentis的朋友們的讚助，DevOps Unbound，非常感謝Tricentis的讚助。但這是媒體活動。
讓我介紹一下今天的小組成員然後我們就開始我們的話題。讓我先介紹一下那個有機器人做背景的人:保羅·布魯斯，穿著404襯衫。保羅,歡迎。為什麼不向我們的觀眾介紹一下你自己呢?
保羅·布魯斯:當然。謝謝你,艾倫。我叫保羅·布魯斯，就像你說的。我是書呆子。我是一個性能和可靠性極客。這是我喜歡的一個複雜的地方這隻是我的包;這就是我喜歡做的事。另一方麵，我是一個社區組織者。我在DevOpsDays Boston和Boston DevOps Meetup工作。今年，我和Liz Fong-Jones一起舉辦了一場名為“o11yfest”的活動，圍繞可觀測性展開，這是一場供應商中立的、以社區為中心的、以開放遙測項目為重點的為期兩天的活動。 It’s half days so that we don’t burn people out. And I work with the Tricentis team since the NeoLoad acquisition – again, performance reliability. I was with Neotys and NeoLoad for years now. I really loved that team. And I love my new one, the broader one at Tricentis. So, that’s me.
Shimel:非常酷。謝謝你,保羅。然後，今天和保羅一起的是——我們非常幸運能請到她——在過去的一年裏，我很高興采訪了她多次，但希望很快能見到她本人，她是我的朋友Christine Yen。克裏斯汀是蜂巢公司的CEO。克裏斯汀,歡迎你。
克裏斯汀日元:你好。很高興來到這裏。艾倫，你的頭銜和我一樣，但我的背景是產品工程師。蜂巢，對於任何不熟悉它的人來說，是一個工具——一個可觀察性的工具。我喜歡從事這方麵的工作，我喜歡談論這個話題，因為盡管我更傾向於軟件工程方麵，但我已經完成了我的工作，因此這個話題對我來說是非常重要的，讓軟件工程師少做些工作，更快地發現他們的代碼真正做了什麼。
Shimel:非常酷。謝謝你,克裏斯汀。很高興你能來。最後但並非最不重要的是我在DevOps Unbound的搭檔。我們在一起工作的時間可能比我們自己都願意承認的要長，但很難相信我們都隻有25歲。但MediaOps的首席技術官，加速戰略集團的首席執行官，米奇·阿什利。嗨,米奇。受歡迎的。
米奇·希禮:謝謝你,艾倫。但最好的25人——今年還是這樣。25了,對吧?
Shimel:對，又是25。
希禮:很高興來到這裏。
Shimel:不管怎樣——是的。謝謝你,米奇。所以，今天的節目，真的，我們將探索交集，或者說是性能，性能測試，和可觀察性之間的邊界。他們是怎麼好好相處的?相互作用是什麼?這是什麼關係?對於我們的觀眾，你可能會看著它說，“好吧，可觀察性幾乎是部署後的。希望我們能在部署前和部署後進行一些性能測試。”但是，我不知道我是否馬上看到了一個聯係，但在我的腦海中有一個明顯的聯係。有明顯的聯係。
所以，讓我們從高層次來討論這個問題。可觀察性和性能測試是如何聯係在一起的?我們怎樣才能在性能測試和可觀察性中得到1加1等於5或4 ?克莉絲汀，如果可以的話，我想讓你從這裏開始然後列出框架，基本規則，然後我們就從這裏開始。
日元:一大清早就把框架和基本規則講清楚有點困難，但我會盡我所能的。
Shimel:好的。我相信你會做得很好的。
日元:我穿錯襯衫了。我經常——我想我曾經帶著我的“生產測試”襯衫參加過一次麵試，但是這個短語被太多的人——可以用多種方式解釋。生產中的測試意味著什麼?有一種說法是，我不會事先進行測試;我隻是想看看是什麼破壞了生產，並試圖在影響到用戶後修複它。顯然，我們都不是這個意思。有一個版本的意思是，嘿，看，當你寫預生產測試，當你寫任何類型的測試，你試圖做的是你試圖比較實際和期望。你試圖形成一個假設，觀察現實，然後思考這個差異。這難道不是我們在生產環境中所嚐試的不同措辭嗎?在生產環境中，我們使用日誌、監視或可觀察性工具來查看代碼在生產環境中實際發生了什麼?
所以，我喜歡-我認為這是一個巨大的交集，一個巨大的重疊，在性能測試和可觀察性之間因為我們都使用相同的技能集，我們都使用相同的大腦序列，但人們似乎認為可觀察性可以更令人興奮因為它是事件，停機和警報響起。我不這麼認為。我認為都是一樣的。這隻是在開發生命周期的不同階段。它在不同的時間軸上。這件事的緊迫性是不同的。但這是同一件事，我們都在嚐試提出假設，驗證它們，然後學習。
希禮:我真的很喜歡，克裏斯汀，你把它們交叉在一起的方式因為我們所處的環境所有這些都發生了很大的變化。不久以前，它還是一種靜態的代碼編寫流程，我們會測試它，我們會CI/CD，我們會測試它，我們會將它部署到生產環境中。而DevOps通過自動化和工具，當然還有用於測試的自動化工具，幫助加速了這一進程。但是現在軟件棧是流動的。基礎設施是流動的。代碼是流動的，因為我們可能對容器(例如，在雲本地應用程序中)引入了三個新的更改，因為我們確實有機會去調試或確定這些更改的來源。我們也有動態的應用程序，啟動後就消失了，而當我們真正看到它們的時候，這些東西可能早就消失了。所以，我認為這種可觀察性的關鍵是讓你洞察到當時可能不存在的環境，所以你需要這些信息來理解“這真的是我需要修複的東西”——一個bug，一個功能，無論它是什麼。
布魯斯:是的，我認為在給係統施加壓力之間有很多交集，無論是通過實際用戶和冒著收益的風險，還是進行預發布類型的測試或在生產中進行測試。績效是指這個係統的表現如何達到預期?不同的人有不同的期望。有一個技術上的期望，可能是表達出來的-希望表達在合法的SLO或-然後用sli之類的東西來衡量它們。但還有用戶期望。這是CEO的期望。B2B。如果你在某種受監管的行業，SLA實際上是法律要求的一部分，這變得非常重要。就像，我們看到失業網站-我不是想挑那種工作，但那是一團糟。同樣的事情發生在各種各樣的事情上，比如接種疫苗等等。 And it’s like why are we still suffering from these systems that are out there and they’re good enough maybe for the day to day but have never been exercised, have never been – the concept of that being – that scaling has never really come about for that system.
好吧，那麼那些默認具有可擴展性的係統呢?回到克裏斯汀說過的一些東西——事實上，克裏斯汀，我很喜歡——你的聯合創始人查莉蒂有一個短語，我要把它抹掉，但“開車時戴眼鏡從來都不是一個好主意。”如果你看不到發生了什麼，那就是一個大問題。
所以，許多人通常會使用類似於“讓我們將所有APM工具投入到生產中。”這是偉大的。但是回到最開始我說的係統上的壓力真的顯示了我們在工程上做得有多好，壓力的影響也很重要。所以，作為一名性能工程師，性能和可靠性工程師，我不隻是像我的法國團隊說的那樣在係統上增加負載，給係統施加壓力，我還非常關心能否衡量這些影響。
我就停在這裏，因為我們可能還有其他問題。但關於這一點還有很多。這不是非此即彼的問題。這不僅僅是關於製作或前期製作。這是關於什麼不是一個好主意的可見性。讓一件事物具有曝光度難道不是一個好主意嗎?不管是在發行前創造曝光度還是在生產中創造曝光度都是如此。我們有很多客戶在生產係統上進行負載測試。這不是不可能的事，夥計們，你們知道嗎?
Shimel:那麼，讓我試著把這個放到一個我們可以跳到的環境中。所以，這就是我所說的克莉絲汀所說的，那就是——也許我要把它提升幾個檔次，走出SLO的森林——最後我們都想要什麼?我們都希望我們的應用程序和基礎設施運行得更好。我們想要對事物的運行有良好的可預測性和可視性。不管這是性能測試的一個方麵，還是你想叫它性能監控，或者你想叫它可觀察性，最終目標是相同的，那就是讓我們了解我們的東西是如何運行的並確保它以我們認為它應該運行的方式運行。所以，在一個非常高的水平上，它幾乎等同於性能或可觀察性——我的意思是，所有的目標都是相同的，那就是讓我們確保我們的東西運行良好，盡我們所能。
在我腦海中,克裏斯汀,我將聽從你,當然在過去的一年,一年半,也許兩個連,可觀測性了,變得更加的炒作和一個真正的詞,一個真正的東西,已經幾乎在一個更大的使命,它並不等同於——我們的目標可能是“嘿,讓我們確保事情是運行最好的我們可以使他們跑,我們期望他們如何運行,”但是，可觀察性有一個完整的超級任務，即人們想用它做什麼或用它來做什麼。保羅，你提到APM。這種可觀察性包含了APM, AI行動等等。但是，等等，還有更多。可觀察性的作用不止於此。這已經變成了一件大事。也許這是對的，也許這是錯的。我不是來評判你的。
但我認為，這才是問題的關鍵。是啊，我們都有相同的目標。可觀察性——可觀察性對性能工程師有幫助嗎?絕對的。還有更多的可觀察性嗎?我想是的。克裏斯汀，你是觀察力專家。我要問你。
日元:你知道當你把一個詞說了足夠多次，它就開始失去意義，你就會覺得“這聽起來有點好笑”?
Shimel:是的。
日元:我們-我認為你-這裏-我們肯定是接近那個有一點可觀測性。每當我說到這一點的時候，我喜歡停下來提醒大家:“讓我們看看——讓我們深呼吸，看看我們用來描述這個的英語單詞。這不是一桶流行語。它不是一個裝滿各種類型數據的桶。這是一種看的能力。這是一種洞察我們生產係統的能力。你想用它做什麼?如果你的視力提高了，你可以用它做什麼?”
好了，現在我們有了一份清單列出了所有我們可以做的事情一旦我們有能力看到這些係統，就像Mitchell提到的，和五到十年前是如此不同。
Shimel:哦,是的。
日元:對我來說，當我感覺我們在努力做所有的事情時，這種縮小的行為讓我重新集中精神。你可能會說“嗯，這有點道理。我想開車的時候戴上眼鏡。”
Shimel:是的。保羅?
布魯斯:克裏斯汀，關於旋轉木馬你說得很對。我在“DevOps”上就有過這樣的經曆。我曾經有過這樣的經曆——哦，天哪，我不敢相信我又說了一遍，但我必須說，因為人們會知道——“左移”。這些項就得到了所有的東西。我們嚐試這些東西，這些不同的術語，我們抓住它們，我們試圖把它變成我們自己的。天啊，小販們喜歡這麼做。我們會用一個詞，我們會把它變成我們的，我們會努力使它與我們的產品戰略相一致。在一天結束的時候，就像有15萬個不同的版本，作為一個表演的人，我有點像“嗯，有一個大的樣本集是不錯的”，但樣本集在交付鏈上發生了什麼，從好的想法到工作的軟件，讓你賺錢不隻是在生產中。
讓我們以耐克為例。這是一個眾所周知的事情，他們發貨手表，你在聖誕節打開手表，你去連接到互聯網，因為服務器被淹沒了，你沒有一個好的聖誕節體驗。這不是唯一的——我隻是挑刺……但這種情況下，你可以做很多事情來防止明顯的錯誤發展到糟糕的體驗的地步。你還需要在生產出現問題的那一天讓人知道。這不僅僅是一天;這是每一天。在生產係統中，每天都有一些數量不為零的事件和問題。你如何解決這些問題?在很多情況下如果你隻考慮可觀察性因為它隻適用於生產順便說一下，生產是讓你賺錢的地方。如果代碼沒有在生產中為人們做一些有用的事情，那麼你就沒有必要從它身上賺錢。 And production isn’t just out for consumers. It could be all the different constituents in your larger organization. So, even private systems are production. And so, if something is not out there then it’s not making money.
那麼，這是否是我們應該關注的唯一地方，我們應該對日誌、跟蹤和度量有良好的可見性，理解業務如何受到影響，以及這些係統中長而複雜的隊列和延遲?不。我的意思是，是的，在我們的邊緣和最終生產係統中，是的，我們當然希望這樣，因為我們不希望在一個糟糕的情況下，當生產中發生問題時，沒有正確的可視性。但是你認為生產過程中會出現什麼問題呢?嗯，有一些緊急的，我們不可能知道。一天的時間太長了。但還有一大堆其他的事情。每一行代碼都不僅僅是一種資產;這是一個責任。所以，當你不斷地推出這些東西時，你可以做很多事情來防止明顯的——我是說愚蠢的、愚蠢的、明顯的東西出現，導致辛勞、浪費、風險、品牌、收入的損失，以及所有這些東西。
所以，我認為對我來說，可觀察性不隻是在生產中。在預生產環境中進行經典的監控是非常有用的，隻是它非常昂貴。哦。然後是可觀察性，部分可觀察性，克裏斯汀可能會更好地講，所有你能做的事情和你從中得到的東西，現在我們可以有用例，這也適用於生產前期的情況。這就是為什麼我對那個開放的遙測項目和那裏的社區如此興奮，這個概念能夠從你的係統中發出信息，要麼直接從你的係統中構建它，要麼在事實發生後把它放上去，某種程度上取代了一些明顯的早期代理類型的東西監控曾經是唯一能做的事情。這種開放式遙測技術現在成為了一種標準，無論在何種環境下，我們都能從中受益。那麼所有環境呢?那就太好了。從Web應用程序一直到數據庫和它接觸的30個不同的api來獲得跟蹤和追蹤。
這真的很有用，不僅可以在生產中進行戰鬥，還可以看到“我是否在冒依賴關係的風險?”我是不是完全脫離了我的架構圖?”你明白我的意思嗎?這些幻燈片。您所設想的架構圖永遠不會是實際運行在生產環境中的。所以，真正能夠看到它是非常重要的。
希禮:嗯，保羅，你知道，生產和測試之間的界限是模糊的，用一個短語——真的有點模糊，通常當我們采用任何新技術或方法時，我們會嚐試做我們過去隻使用新技術去做的事情。我們用以前的方法來測試。早期讓我對雲計算產生共鳴的是Netflix如何進行滾動升級，並能夠來回切換。對於測試和性能測試也是如此，因為您對資源的可用性通常不是問題，或者在您不在雲中或至少部分在雲中的環境中通常不是問題。因此，您不僅可以在當前的測試環境中做很多事情，而且還可以設置一個相當複雜的環境—使用資源進行不同的負載測試、性能測試場景，以及您在生產環境中所經曆的事情。
我認為你提出的一個要點很突出，如果你注意到這一點，你就會對你的係統，你的應用，你的環境有足夠的了解來識別"好吧，我們可能能夠處理我們今天收到的失業申請的數量但我知道當我們到達下一個高峰時這三件事將會受到影響。我知道這些都是我們需要調整或解決的問題。”因為你已經測量得足夠好了你通過可觀察性獲得了信息，可以做到這一點。所以，我認為這是我們看待性能測試的另一種心態。
Shimel:是的。所以，我告訴你，我認為DevOps最大的突破之一就是創造出更逼真、更真實的“測試環境”。我的意思是，在DevOps之前，在我成長的世界裏，最經典的事情是，開發人員開發出來，把它給了運維人員，運維人員把它放在上麵說，“等一下，這個東西不能運行。”他說，嘿，開發者，這個不能運行開發者說:“我不知道，夥計。它在我的機器上運行。”因此，在開發人員編寫和運行它或測試它與實際生產環境之間存在脫節。雲計算和虛擬化的好處之一就是理論上我們可以複製我們的生產環境和測試環境我們可以增加負載理論上我們可以做所有這些事情這樣當我們投入生產時就不會有任何意外。那——看，那——謝謝你，DevOps。我認為這是整個DevOps的一部分。
但我不知道，克裏斯汀，那真的是狗獵還是DevOps的都市傳說?你知道嗎?
日元:我認為你做得很好。我的意思是，當Charity和我一起創建Honeycomb時，她的想法是正確的——你講的那個故事，我就是那個開發者;她就是那次行動的人。我做了整個“它在我的機器上工作;我不知道你在說什麼。”當我們創建蜂巢的時候，我們認為我們將與世界上更多的慈善機構進行交流。我們說，“哦，這是為行動人員準備的工具。他們理解那種痛苦。”隨著蜂巢的增長，隨著可觀察性的增長，它變得越來越明顯:“不，這也是為全世界的基督徒準備的。”這是為那些需要了解在測試環境之外會發生什麼的人準備的。 This is – the boundaries are blurring or – I like to think of it as dev and production are coming closer together because there are more and more things we just can’t test in a test environment. As good as we make the test environment, we just can’t.
Shimel:我完全同意。
日元:通過將生產看作開發環境的一部分，我們可以學到很多東西——這是一樣的。有了特性標誌，我們就可以開始使用那些還沒有準備好用於生產的代碼，但可以用安全的方式進行測試，並從中學習。這太酷了。當每個人都克服“開發和生產之間有一堵牆”的心態時，開發者可以學到很多東西。沒有。人和軟件之間不應該有隔閡。所有令人興奮的部分都在那裏。
Shimel:我不反對。我不反對。
布魯斯:艾倫，你說過一件事——你畫了一個舞台，這樣我們就可以進行對話。我不喜歡設置巨大的舞台環境。在經典的世界中，它就像，好吧，這是生產，它使用36個Oracle後端，如果我們要運行一個適當的性能測試，我們當然需要36個。在雲計算出現之前，那是非常昂貴的，你給你的IT人員發傳真，他們會在六個月後拿回正確的硬件。我認為這是一個誤區，嗯，是的，在某些時候你需要現實一點，特別是當你對一個係統施加壓力時，要回答最後一個問題，那就是-什麼?——它準備好讓我成為——什麼?-有足夠的信心這個東西會像我們在標準中談論的那樣過渡，過渡過程，實際上會順利進行?不是用瀑布式的方式，隻是為了擺脫"它在我的機器上工作"的概念現在操作人員正在滅火卻不知道如何操作它。
但我不喜歡在這個分期係統上花很多錢，因為即使在根本上它和生產係統是一樣的，角落裏總有個混蛋說:“是的，但這不是生產係統。”就像“好吧，你有道理，但你不知道發生了什麼。”關鍵是，我想的有點像-我要做我的蠢事了引入一個數學概念，然後可能會出錯，一個關於極限的數學概念。你還記得限製嗎?我們的想法是，我們需要能夠表達我們在談論事物的終極目標嗎?不，這是一個連續體。
所以，有很多與我合作的公司實際上都有要求，他們在將其轉化為生產之前要經過大量的測試和特殊的事情。他們不能像對待開發係統一樣對待產品。世界上有很多人，這不是他們的功能障礙——這不是功能障礙，僅僅因為獨角獸們可以放彩虹屁，打噴嚏，發射任何他們想要的東西。我在波士頓的一些創業公司中經常看到這種情況，他們確實把自己置於風險之中。即使你不這樣做，當你有一個極端的成熟度，你使用相對複雜的技術，如Kafka，事情可能很快出錯。問題是當這些事情實時發生的時候你是否有人員，流程，技術，知識，經驗和專業知識來處理這些?
你怎麼去那裏?你如何找到那些知道如何有效使用你的監控和可觀察性工具的人?您如何知道這些係統，您所感知的架構與實際生產中的架構有多接近，您如何知道有多少增量?您可能會問自己的另一個經典問題是，您多久進行一次災難恢複過程。
回來,誰會交火時或者在最後關頭的事情像我們所做的一些公司,我通過NeoLoad密切共事方麵,在教育係統時,當學校關閉,他們終於說,“我們關閉大門支付我們錢的人,”這是一個可怕的和真正的和重要的國旗的美國教育係統“神聖的廢話。在過去的幾個月裏，我們必須提供虛擬服務，而不是作為權宜之計，但這將是我們明年麵臨的嚴峻現實。”
因此，很多幫助教育係統的供應商都有合適的平台。他們會說:“天哪。我們真的需要測試10倍於我們之前測試過的尺寸。”所以，他們在不同的地方用晚上和周末的時間進行生產測試，並且以較小的速度進行。但他們找的是誰?不隻是捉鬼敢死隊，還有開發人員和行動人員。有來自基礎設施和DBA團隊的人。他們有20多人在電話中緊張得要死，就像(發出顫抖的聲音)——緊張得要死，這是一大筆錢。順便說一下，你要求他們從晚上10點到淩晨2點到淩晨3點工作。因此，他們不可能在所有那些花哨的會議上使用，他們應該是涉眾的架構會議。
所以，當你要做那些巨大的事情的時候有時候你需要做得更大。但是絕大多數的鍛煉，都是去健身房的不是我，而是去健身房鍛煉。你去騎上你的自行車，這是一個練習。你不會指望在沒有鍛煉的情況下就能跑完一場比賽，在你跑完一場5公裏比賽之前，你不會對這條路有一點了解。那麼，為什麼你希望你的係統和團隊這樣做呢?
這就是一些測試，低階性能測試發揮作用的地方。它將事物係統化，創造了一個可以執行和重新執行的過程，無論它指向哪個環境。你從中得到的遙測技術在每個環境中都是一致的。如果突然之間，我們在生產前的環境中有了很好的遙測技術，但在生產中卻沒有，這將是一個大問題。為什麼它被放在這裏，卻沒有在生產中表現出來?如果我們需要它呢?反之亦然:我們隻在生產中做事情，所以現在隻有——有一些隻在生產中做的事情沒有在較低的環境中表現出來。
所以，保持這些事情的同步同時保持過程和練習的技能是為什麼這不僅僅是一個大的環境在最後的情況。
Shimel:再次，我認為“謝謝你，DevOps”，在那裏我們可以說，好的，我們不僅需要這些或者我們可以使用這些測試開發環境，而且就像Christine說的，有了功能標誌和其他一些我們使用的技術，過程，這是有可能繼續的-反饋循環和實時迭代，同時在生產中使用。這也是讓我們能夠不斷更新、不斷迭代、不斷的原因之一，反饋循環是DevOps的一個原始概念。我們會有這些反饋循環，我們會反複迭代。
但是我們已經做到了可觀察性和性能測試這些事情已經真正打開了閘門我們現在如何做這些事情。我的意思是，想想八年前我剛創建DevOps.com的時候，有些獨角獸每天都要更新好幾次。但對世界上的許多人，對世界上的許多組織來說，看，從一年一次到一年兩次，從一年兩次到每季度，每季度到每月，這是巨大的。這是巨大的。它不再那麼大了。對於人們來說，每天更新代碼或者每天更新不止一次是很常見的。
我這周做了一個采訪，一個關於開發者的最新調查，他們聲稱在過去的一年半裏他們的部署速度提高了100%。大概有70%的開發者這麼說。想想。我的意思是，這裏10億，那裏10億，你說的是真錢。70%的開發者表示他們的速度提高了100%。哇。哇。這是多麼美好的時光啊。這是因為可觀察性，DevOps，我們更好的性能測試。無論如何。
夥計們，我們的時間快到了。我想-我們結束吧。讓我們——對在這裏收聽和觀看的人們有什麼建議，我們能給他們什麼?關於這種可觀察性和表現之間的聯係，我們能告訴他們什麼，讓他們的生活變得更好?保羅，我要——如果你不介意的話，我要讓你處於尷尬的境地，讓你先說。
布魯斯:當然。有幾件事我已經研究了一段時間還有幾件事我想大聲說出來。我先說-克裏斯汀不能做推介，但我可以。蜂巢是可怕的。你在比賽中看到它，它是了不起的，因為它背後的團隊是了不起的。你明白我的意思嗎?這有點像康威法則，我聽到最多的說法是係統是構建它們的團隊的結果。所以，一定要去看看。
其他工具也是一樣。但是不要太過關注整個可觀察性——不要隻關注“可觀察性”而隻關注第一個，因為大多數人都在為那裏的SEO位置花大價錢。真正地看看有什麼可用的，然後再去挖掘團隊，博客，以及背後的精神。
我建議的第二件事是我們剛剛發布的——我是DevOps原則和實踐標準工作組的成員之一，該標準適用於高度監管的行業。它是IEEE 2675-2021，我們希望它能被ISO采納，所以它也是全球性的。它所做的是真正對齊的是-每一個重要的過程是如何在許多不同的生命周期中持續應用的?你知道，DevOps永恒的標誌意味著我們將永遠被困在地獄裏，那件事正在發生，所有的事情都在發生，但在高度監管的行業裏，有一些精確的事情需要發生，甚至不需要。所以，我們已經為此工作了四年。如果你想知道更多，你可以在LinkedIn或者Twitter上聯係我——盡管LinkedIn可能是更好的方式——如果你想知道更多。
但本質上，這是許多人投入時間和精力的工作，他們說:“嘿，看，這不是關於DevOps是什麼。這是關於如何在這些複雜的情況下做到這一點。”你認識我;作為一個表現極客，我參與了質量管理/質量保證，驗證，確認，風險管理過程，諸如此類的事情。我試圖確保有證據的決定，這是一個鉤，基本上說可見性，遙測，適當的SLOs到位，這些肯定是在標準和其他東西。
所以，一定要看看這兩件事:蜂巢和IEEE 2675。
Shimel:好的,保羅。克裏斯汀。
日元:謝謝你的發言，保羅。我想讓大家記住的一個建議是，我們已經談了很多——或者說，我已經談了一些關於開發人員在生產和開發人員在可觀察性。這裏有一個星號，那不是——實踐——肌肉和實踐應該轉移得很好，但在DevOps世界的生產中有很多事情，在某些情況下是完全敵視開發人員的，在許多情況下隻是有點可怕和陌生。所以，如果這對你來說很有趣，如果你覺得“啊，是的，我也想把開發和生產更緊密地結合在一起”，那就退一步去尋找類似的東西。你的生產工具主要談論AWS實例、CPU和內存使用嗎?這些可能會嚇跑你的開發者。如何讓開發人員更熟悉生產工具中提到的詞彙?你如何幫助他們把他們在測試中習慣的概念和名詞——客戶ID或端點或邏輯，這些對開發人員來說更熟悉的東西，你如何讓這些也存在於你的生產工具中，這樣開發人員就可以出現，並像“哦，哦，這沒什麼不同”?
我認為在特定的實踐中有很多東西被編碼了，因為我們假設某個特定的角色是使用它們的人。這些牆正在變得模糊，或者說這些牆正在倒塌;那些邊緣正在模糊。還有一些工作要做來促進它。
Shimel:絕對的。米奇爾，你想帶回家嗎?
希禮:是的，我將以這種方式結束它，因為有一些非常實用的建議——順便說一下，兩家公司都有很棒的產品，所以請看看它們。我認為我們有這種思維模式，這種以一種狀態思考事物的習慣。物質有四種狀態如果你算上希格斯玻色子，就有五種狀態玻色希格斯玻色子。它不僅僅是固體。它也是液體。我的意思是，想想我們的係統。不要把它看作軟件工具，它的所有層次。它們結合在一起更像一種流體，處於不斷變化、不斷移動的狀態。正在發生的事情。這就需要重新考慮開發人員和產品，在生產環境中進行性能測試。 And the flow of software through that DevOps tool chain is really part of that – the fluidity of that state.
所以，我認為我們喜歡這樣想——把所有東西都變成固體，這樣它就不會改變，這樣我們就可以觀察它，觀察它，對它做點什麼其實不是這樣的。這不是我們今天生活的世界。但如果你把它想成是一種像流體一樣不斷變化的東西，那麼我認為我們有更好的機會找到更好的方法，無論是通過技術，新的範式，新的工作方式，如何使我們的軟件絕對是最好的。
Shimel:說到底，這是我們所有人都在爭取的。對吧?
好的。這樣結束這一切真是太好了。到此結束。應該是《DevOps Unbound》的第13集。但不管這個數是多少，它都是流動的。這是DevOps Unbound的最後一集。非常感謝Tricentis對我們DevOps Unbound的讚助。我們將在兩周後帶著另一集精彩的節目回來。請繼續關注。這個月我們還有一個大型圓桌會議; check that out.
保羅，恭喜你加入特裏森提斯團隊作為收購的一部分。
布魯斯:謝謝你！
Shimel:克裏斯汀，他們都說蜂巢很好，但實至名歸。也替我們向慈善機構問好。
日元:我會的。謝謝你！
Shimel:繼續做你正在做的事情。我希望很快或幾個月後能見到你們。也許我們會在某個時間做一個DevOps Unbound。但在那之前，我是媒體行動的艾倫·謝梅爾。你剛剛看了《DevOps Unbound》。
(音頻結束)
