在最近於阿姆斯特丹舉行的事件驅動微服務大會上，russ miles聲稱，架構師面臨的最大挑戰是自身被忽視。你有很多很好的想法，比如事件驅動的微服務，但通常的反應是，這些主意聽起來不錯，但是對於手頭要解決的問題來說過於複雜。當miles建議公司應該考慮將非同步事件驅動系統作為實現伸縮、冗餘和容錯的一種方式時，通常會收到這種反應。這些術語聽起來通常對公司來說是有意義的，但同樣經常被忽略。
\\ miles的主要工作目標是構建可靠的系統。對於他而言，可靠性是客戶需求的一種考量，客戶需要的是乙個功能豐富且始終能正常執行的系統。這意味著我們有兩股不容易共存的對立力量，特別是在複雜的系統中——一方面是持續的創新和變化，一方面是能夠一直正常執行的系統。
\\ 根據miles的說法，對於架構師來說最困難的事情就是讓每個人都明白你正在構建乙個具備彈性的系統。miles強調，他不僅僅是在談論技術，而是指整個系統，包括人員、實踐和流程。基於這些原因，他認為乙個生產系統能夠正常運作簡直就是乙個小小的奇蹟。
\\ miles引用了john allspaw對彈性的定義。如果你構建的系統具備冗餘、複製和分布式等特點，那麼你可能正在構建乙個健壯的系統。allspaw認為，當涉及人員時才能叫彈性。同樣，混沌工程也超出了工具的範疇——它是關於人們如何思考和實現系統。
\\ 在miles看來，混沌工程是一種在故障發生之前發現故障的技術，但也是一種心態：\\
miles認為，混沌工程最重要的一點是你必須成為系統團隊的一員。你不能成為破壞系統然後等待別人去解決問題的人。你必須參與你所做的一切，並與其他人一起修復問題。miles已經看到一些公司專門成立團隊對系統實施破壞，但根據他的經驗，這樣是起不到混沌工程的作用的。
\\ miles指出，在他看來，混沌工程很簡單，因為只有兩個主要的關鍵實踐需要學習。他認為這不需要任何認證計畫：\\
如果你準備好開始在公司裡實踐混沌工程，miles的第乙個建議就是不要使用這個術語本身。不要談論破壞系統，而是談論已經發生的事故以及你可以從中學到什麼並加以改進。他指出，你正處於乙個學習迴圈中，試圖讓系統逐步變得越來越有彈性。
\\ miles總結了一些必須遵循的「混沌俱樂部」規則：
\\ 不要談論混沌。這些概念正在變得越來越主流，但這個術語可能仍然會讓人們感到失望。當人們感到能夠適應時才開始使用它。\\t
在不破壞系統的情況下總結經驗。你試圖趕在使用者之前找到並處理系統弱點，從而改善整個系統。\\t
混沌不應該是乙個驚喜。\\t
如果你知道系統會中斷，請不要進行實驗。在嘗試尋找新的系統弱點之前，先嘗試解決你已經知道的系統弱點。\
在開發基於事件驅動的微服務系統時，最難的一件事情就是讓開發人員了解如何讓微服務在生產環境中有良好的表現。這包括使用正確的端點來宣告服務的健康狀況，並使用正確的接觸點來說明服務是否執行正常。良好的日誌記錄是乙個重要的方面，改進這一點的方法是讓開發人員閱讀他們自己的日誌，例如，在遊戲日，他們必須通過他們自己的日誌了解系統都發生了什麼。
\\ 在進行混沌工程時，使用事件溯源系統可以帶來可觀察性。在miles看來，可觀察性意味著能夠在不改變生產系統的情況下對其進行除錯。如果你正在進行某種形式的混沌實驗，那麼你要做的第一件事就是除錯系統以便找出問題所在，並使用事件源系統，這樣你就可以確切知道發生了什麼以及何時發生的。
\\ miles最後說，這是他職業生涯中第一次遇到了最佳實踐。對於我們今天構建的複雜系統，混沌工程是一種可行的技術。通過手動的方式做少量的操作，可以採取遊戲日或任何適合你的方式。如果你關心系統的可靠性或彈性，它應該是乙個比較適合你的工具。
\\檢視英文原文：russ miles: ignored architects and chaos engineering
Russ Miles 被忽略的架構師和混沌工程
在最近於阿姆斯特丹舉行的事件驅動微服務大會上，russ miles聲稱，架構師面臨的最大挑戰是自身被忽視。你有很多很好的想法，比如事件驅動的微服務，但通常的反應是，這些主意聽起來不錯，但是對於手頭要解決的問題來說過於複雜。當miles建議公司應該考慮將非同步事件驅動系統作為實現伸縮 冗餘和容錯的一種...
Russ Miles 被忽略的架構師和混沌工程
在最近於阿姆斯特丹舉行的事件驅動微服務大會上，russ miles聲稱，架構師面臨的最大挑戰是自身被忽視。你有很多很好的想法，比如事件驅動的微服務，但通常的反應是，這些主意聽起來不錯，但是對於手頭要解決的問題來說過於複雜。當miles建議公司應該考慮將非同步事件驅動系統作為實現伸縮 冗餘和容錯的一種...
請求被忽略
這個例子顯示了兩個有趣的東西。首先，雖然我們要求200的能力，我們實際上有乙個容量207。能力總是保證至少和你一樣大的要求，但可能更大。然後我們要求的能力改變以適應字串。這個請求被忽略，因為能力並沒有改變。如果你事先知道你要做大量的字串操作，將新增到字串的大小構建乙個大的字串，你可以避免字串分配多次...