姆吉拉假面 時間不夠怎么辦

反思我公司通往微服務，DevOps和完美價值流的旅程

在制造業中，價值流圖（VSM）是用于衡量績效的流行工具。 VSM由Toyota聞名，實質上是流程圖，描述了創造價值的必要步驟。

例如，為椅子工廠考慮此簡單的VSM。

椅子工廠的VSM示例。

此示例說明了工廠在收到訂單后需要制作椅子的四個步驟：焊接，噴漆，組裝和檢查。

這里有兩點值得指出。

這些步驟必須按順序完成。 在此示例中，必須在焊接后為每把椅子進行繪畫。

這些步驟可以針對不同的工作項目并行完成。 在此示例中，這意味著涂漆和焊接可以同時進行，但適用于2個不同的椅子。

VSM的總時間是所有步驟的總和。 在此示例中，每把椅子從開始到結束需要7天。

輸出速率是工作項可以流過VSM的速度。 在此示例中，如果每個步驟始終有椅子需要加工，我們的工廠每3天可以生產1把椅子。

我們的椅子工廠滿負荷工作，每3天可以生產1把椅子。

最后一點特別值得注意，因為它說明了總時間和輸出速率之間的差異。 在決定如何改善流程時，輸出率說明了為什么我們應該專注于最長的步驟（或最大的瓶頸）。 在此示例中，我們的工作流僅受檢查約束。

此示例與椅子有關，但是Value Steam Maps也可以描述軟件交付。 考慮下面的另一個VSM； 這類似于制作椅子。

用于軟件交付的VSM示例。

在此軟件示例中，“部署”是最長的步驟，這意味著盡管其他步驟有多快，但每個功能請求的輸出速率至少為3天。 換句話說，此VSM告訴我們Deploy實際上是我們的唯一約束。

以上兩個示例都是過分簡化的“價值流圖”，但它們說明了為什么只有最大的瓶頸才重要。 當我反思我公司的架構在過去幾年中如何發展時，我意識到正是這些瓶頸引導了我們一些最大的變化。

瓶頸如何引導我們的基礎架構的故事

最初，我公司的旅程始于幾個開發人員，而沒有其他人。 因為團隊很小，所以協調很容易，并且因為不存在任何遺留系統，因此無法提供支持。 這提供了確定業務和產品的敏捷性。 我們的價值流很清晰。

僅有幾個開發人員和一個新的Rails項目

然后我們的公司成長了。 用戶增加，產品不斷發展，這意味著需要新的系統。 但是管理這些系統需要我們花時間去開發。 這成為我們的第一個瓶頸。 因此，我們引入了Capistrano和Puppet之類的工具來管理我們的系統，因此解決了我們的第一個大瓶頸。

更多的系統需要使用Puppet和Capistrano等工具來管理它們。

但是我們的公司繼續發展。 出現了更多的開發人員，以及更多的部署，修補程序和配置。 我們的自動化有所幫助，但是許多任務仍然需要我們唯一的Sysadmin進行人工協助，而他很快就變得不知所措。 這成為了我們的第二大瓶頸，結果，雇用了更多的Sysadmin管理員，并組建了基礎架構（或SRE ）團隊。

需要更多人和團隊的SRE團隊來處理他們的所有要求

此時，我們主要使用Ruby和MySQL，而我們的SRE團隊允許我們進行擴展。 但是很快我們將需要JavaScript和Scala，以及Kafka集群和Cassandra數據庫。 這成為了我們的下一個瓶頸，因為我們引入的每項新技術都產生了獨特的要求，這些要求阻礙了SRE團隊進行系統特定的程序。 因此，我們將系統遷移到Docker和一個容器編排（或微服務）平臺上 ，以便隨著技術選擇的擴展，為Sysadmins提供一個通用的界面來支持我們的各種系統。

越來越多的技術要求Docker使其更容易支持各種技術。

容器使我們能夠支持多種技術，但它也鼓勵開發人員更多地參與其系統的操作。 這意味著越來越多的團隊要求Sysadmin管理員更改其容器。 團隊的建設速度越來越快，并且開發的DevOps也越來越多，但是對SRE團隊的依賴成為了新的瓶頸。 認識到我們組織中的這種趨勢，導致創建了一個自助門戶，供開發人員在沒有Sysadmin的情況下（甚至在生產中）應用特定更改。 最初，此門戶允許用戶設置其容器的CPU和內存限制，這是當時最受歡迎的請求，但是隨著其他常見請求（或瓶頸）的出現，功能被添加。

團隊自助服務基礎架構門戶的早期模擬。

該門戶網站使團隊可以自由工作，從而幫助推動了整個公司的DevOps運作，但同時也使我們面臨著圍繞成本管理和訪問控制的新挑戰，不用說，這些挑戰不會終結。 解決這些挑戰后，我們很可能會再次發現更多瓶頸。 瓶頸永遠不會停止，但是請放心，這不是一件壞事。

我們基礎設施的故事并不新鮮，但是我發現啟發人的是認識到我們旅程的無窮無盡。 完美的基礎架構不存在（任何軟件產品都可以如此），但這并不意味著我們應該停止嘗試改進。 到達終點線并不像前進一樣重要。

持續的瓶頸導致持續改進

解決瓶頸是一件好事。 瓶頸代表了可以改進我們的工作方式。 他們通過強迫我們不斷地問自己如何創造價值以及該價值是什么來指導我們的努力。

在我最喜歡的 《社交網絡》中 ，愛德華多問馬克，什么時候可以完成Facebook的建設，這樣他就可以開始通過它獲利了。 馬克恰當地回答說，Facebook永遠不會做，就像時尚永遠不會做一樣。

Facebook永遠不會做

這個場景引起了我的共鳴，因為我認為它不僅適用于Facebook，而且適用于所有形式的手Craft.io品，無論是軟件，藝術品，音樂還是其他東西。 總是可以汲取經驗教訓，可以一直取得增長，就軟件交付而言，Value Streams可以發現導致最有意義的改進的瓶頸。

曾經有人告訴我，構建軟件就像構建鐵路一樣。 該過程從開創性??開始，然后是構建，最后是優化。 盡管這種比較有時很有用，但感覺缺乏“優化”的確定性。 相反，我更喜歡將軟件開發與“星際迷航”相比較，它的持續探索任務就像探索宇宙一樣，從未完成過構建（和改進）工作。 我們只需要決定去哪個方向。

椅子和寫作軟件之間的真正區別

制造和軟件共享持續改進的旅程，但這就是價值流圖的相似之處。 制造業與物質世界打交道。 在工廠車間，您可以看到工作項以及工作流本身。 哪一步是瓶頸和容易出錯甚至可能是顯而易見的。 使用軟件并不是那么容易。

有了軟件，工作就可以實現電子化，而工廠車間則是一個充滿計算機的房間。 很難看到有人要執行的任務或工作流程是什么。 軟件是無形的，這是軟件與制造真正的區別所在，以及為什么像Jira這樣的工具對于此類工作如此重要。

在裝配線上比在辦公室更容易發現進度。

Jira是一個用于軟件團隊的任務管理系統，用于描述和跟蹤工作項目，其進度，所有權，所花費的時間以及其他對于理解效率低下和構建有意義的價值流圖至關重要的信息。 人們通常認為這些任務管理系統僅用于計劃未來的工作，但是其價值的很大一部分來自于他們記錄過去的方式，因此我們可以對其進行合理化以在將來做出更好的決策。

創建票證以跟蹤Jira中的工作項

為了理解開發人員的生產力及其驅動因素，已經做了很多工作。 在DevOps時代，這導致人們認識到部署頻率，變更提前期以及其他此類開發人員指標 。 但是，以我的經驗，沒有什么能比簡單地記錄日記和時間更普遍有效了。 我堅信個人從日記和反思中獲得的收益（例如以下收益）也適用于組織。

• 結合反思，從直接經驗中學習會更有效 。
• 記錄日記以記錄獲勝和挫折（否則可能會遺忘您的記憶）可以為您意識到自己正在取得進步提供動力，并幫助您考慮如何擺脫阻礙進度的抑制因素（甚至是次要的抑制因素）。

對于任何軟件公司而言，最重要的一件事就是了解其如何創造價值。 許多公司會迷失在技術或組織結構之間進行選擇，但這與本質無關。 唯一重要的是如何創造價值以及阻礙發展的障礙。 通過引用這些經驗（使用Jira或其他方法）并進行反思，我們不僅能夠認識到我們遇到的障礙，而且還能揭示前進的道路。

翻譯自: https://hackernoon.com/how-toyota-guides-the-evolution-of-our-infrastructure-and-makes-me-appreciate-jira-bcb766822a3e

姆吉拉假面 時間不夠怎么辦

總結

以上是生活随笔為你收集整理的姆吉拉假面 时间不够怎么办_丰田如何指导我们基础设施的发展（并使我赞赏吉拉）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。