25 月 XNUMX 日，我們 Mail.ru Group 舉辦了一場關於雲和周圍的會議 - 。 幾個亮點：
- 主要的 — Mail.ru Cloud Solutions、#CloudMTS、SberCloud、Selectel、Rostelecom Data Center 和 Yandex.Cloud 談到了我們雲端市場及其服務的具體情況；
- Bitrix24 的同事講述了他們是如何 ;
- Leroy Merlin、Otkritie、漢堡王和施耐德電機提供了有趣的內容 — 他們的企業為 IT 設定了哪些任務以及他們認為最有前途的技術（包括雲端技術）。
您可以觀看 mailto:CLOUD 會議中的所有視頻 ，在這裡您可以閱讀有關微服務的討論如何進行。 MegaFon業務系統研發中心負責人Alexander Deulin和M.Video-Eldorado集團資訊技術總監Sergey Sergeev分享了他們擺脫龐然大物的成功案例。 我們也討論了IT策略、流程甚至HR的相關問題。
小組成員
- 謝爾蓋·謝爾蓋夫, 集團資訊長 《M.Video-埃爾多拉多》;
- 亞歷山大·杜林業務系統研發中心主任 百萬豐;
- 主持人—— 德米特里·拉扎連科, PaaS方向負責人 Mail.ru 雲解決方案.
亞歷山大杜林 (Alexander Deulin) 演講後 M.Video-Eldorado 的 Sergey Sergeev 和 Mail.ru Cloud Solutions 的討論主持人 Dmitry Lazarenko 也參與了討論。
下面我們為您準備了討論記錄，但您也可以觀看影片：
向微服務的過渡是對市場需求的回應
德米特里：
您有遷移到微服務的成功經驗嗎？ 一般來說：您認為使用微服務或從整體遷移到微服務的最大商業利益在哪裡？
謝爾蓋：
我們在向微服務的過渡方面已經取得了一些進展，並且已經使用這種方法三年多了。 證明微服務合理性的第一個需求是各種前端產品與後台的無止盡的整合。 每次我們都被迫進行額外的整合和開發，實施我們自己的規則來操作這個或那個服務。
在某些時候，我們意識到我們需要加快系統的運作和功能的輸出。 當時，市場上已經存在微服務和微服務方法等概念，我們決定嘗試。 這要從 2016 年開始。 然後平台鋪設完畢，前10項服務由單獨的團隊實施。
價格計算服務是最早、負載最重的服務之一。 每次您來到任何管道、M.Video-Eldorado 集團公司，無論是網站還是零售店，在那裡選擇產品，查看網站上或「購物籃」中的價格，費用就會自動計算由一項服務計算。 為什麼這是必要的：在此之前，每個系統都有自己的促銷原則 - 折扣等。 我們的後台處理定價；折扣功能在另一個系統中實現。 這需要集中化，並以業務流程的形式創建一個獨特的、可分離的服務，使我們能夠實現這一點。 我們就是這樣開始的。
第一個結果的價值非常大。 首先，我們能夠創建可分離的實體，使我們能夠單獨並以聚合的方式工作。 其次，我們在與更多系統整合方面降低了擁有成本。
三年來，我們新增了三個一線系統。 用公司所能負擔的同等資源來維持它們是很困難的。 因此，我們面臨的任務是尋找新的出路，以速度、內部成本和效率來回應市場。
如何衡量遷移到微服務是否成功
德米特里：
如何確定遷移到微服務是否成功？ 每家公司的「以前」是什麼？ 您使用什麼指標來決定過渡期是否成功？由誰實際決定？
謝爾蓋：
首先，它誕生於 IT 領域，作為推動者——「解鎖」新功能。 我們需要以相對相同的資金更快地完成所有工作，以應對市場挑戰。 現在，成功體現在不同系統重用的服務數量以及流程之間的統一性。 現在是這樣，但在那一刻，這是一個創建平台並確認我們可以做到這一點的假設的機會，它將產生效果併計算業務案例。
亞歷山大：
成功更多的是一種內在的感覺。 企業總是想要更多，我們積壓的深度就是成功的證明。 對我來說似乎是這樣。
謝爾蓋：
是的我同意。 三年來，我們已經有兩百多個服務和積壓。 團隊內部對資源的需求僅以每年 30% 的速度成長。 發生這種情況是因為人們感到：它更快，它不同，有不同的技術，所有這些都在發展。
微服務將會到來，但核心仍將存在
德米特里：
這就像一個永無止境的過程，你需要投資開發。 業務向微服務的過渡是否已經結束？
謝爾蓋：
這很容易回答。 您認為更換手機是永無止境的過程？ 我們自己每年都會購買手機。 這就是：只要需要速度，為了適應市場，就需要一些改變。 這並不意味著我們放棄標準的東西。
但我們不能一次覆蓋並重做所有事情。 我們擁有先前存在的遺留標準整合服務：企業總線等。 但有積壓，也有需求。 行動應用程式的數量及其功能正在不斷增長。 同時，沒有人說會給你多30%的錢。 也就是說，總是一方面有需求，另一方面又追求效率。
德米特里：
生活狀況良好。 （笑）
亞歷山大：
一般來說，是的。 我們沒有革命性的方法來從景觀中移除核心部分。 正在進行系統性的工作，對系統進行分解，使其更符合微服務架構，並減少系統之間的影響。
但我們計劃保留核心部分，因為在營運商的視野中總會有一些我們購買的平台。 同樣，我們需要一個健康的平衡：我們不應該急於削減核心。 我們將系統並排放置，現在事實證明我們已經掌握了許多核心部分。 此外，在開發功能時，我們為與我們的通訊服務配合使用的所有管道創建了必要的表示。
如何向企業銷售微服務
德米特里：
我也對那些尚未轉行但計劃轉行的人感興趣：將這個想法出售給企業有多容易？這是一次冒險還是投資項目？ 或者這是一個有意識的策略：現在我們要轉向微服務，就這樣，沒有什麼可以阻止我們。 你感覺怎麼樣？
謝爾蓋：
我們出售的不是一種方法，而是一種商業利益。 業務上出現了問題，我們試著解決它。 當時的表現是，不同的管道使用不同的計算價格的原則──分別用於促銷、促銷等。 維護起來很困難，經常出現錯誤，我們也聽取了客戶的投訴。 也就是說，我們正在出售問題的解決方案，但我們面臨的事實是我們需要資金來創建一個平台。 他們使用第一階段投資的例子展示了一個商業案例：我們將如何繼續收回投資以及這將允許我們做什麼。
德米特里：
你有記錄第一階段的時間嗎？
謝爾蓋：
是的，當然。 我們分配了 6 個月的時間來創建核心平台並進行試點測試。 在此期間，我們嘗試創建一個平台供飛行員滑行。 那麼假設就得到了證實，既然可行，那就表示我們可以繼續下去了。 他們開始複製並加強團隊——他們將其轉移到一個單獨的部門來完成這個任務。
接下來是基於業務需求、機會、資源可用性和目前正在進行的一切的系統工作。
德米特里：
好的。 亞歷山大，你說什麼？
亞歷山大：
我們的微服務誕生於「大海的泡沫」——由於節省資源、由於伺服器容量形式的一些剩餘以及團隊內力量的重新分配。 最初，我們沒有將這個項目出售給企業。 這是我們共同研究和開發的一個項目。 我們從2018年初開始，只是滿懷熱情地發展這個方向。 銷售剛開始，我們正在進行中。
德米特里：
是否有企業允許您每周有一天免費做 Google 之類的事情？ 你有這樣的方向嗎？
亞歷山大：
研究的同時，我們也處理業務問題，所以我們所有的微服務都是業務問題的解決方案。 一開始我們建構的微服務只涵蓋了一小部分用戶群，現在我們幾乎出現在所有旗艦產品中。
實質影響已經很明顯——如果我們走老路，我們已經可以計算出來，產品發布的速度和收入損失也可以估計。 這就是我們建構案例的基礎。
微服務：炒作還是必要性？
德米特里：
數字就是數字。 收入或節省的金錢非常重要。 如果你看另一面呢？ 似乎微服務是一種趨勢，一種炒作，許多公司都在濫用它？ 您如何清楚地區分您所做的和不轉化為微服務的事情？ 如果現在有遺產，5年後還會有遺產嗎？ 5 年後，M.Video-Eldorado 和 MegaFon 的資訊系統的年齡會是多少？ 是否會有十年、十五年歷史的資訊系統，還是新一代的資訊系統？ 您對此有何看法？
謝爾蓋：
在我看來，很難想得很遠。 回顧過去，誰能想到科技市場會發展成這樣，包括機器學習、人臉辨識？ 但如果你看看未來幾年，在我看來，公司的核心系統、企業 ERP 等級系統 - 它們已經工作了相當長的時間。
我們的公司總共已有 25 年歷史，經典 ERP 已深入系統領域。 很明顯，我們正在從中取出一些部分並嘗試將它們聚合到微服務中，但核心仍將保留。 我現在很難想像我們會更換那裡的所有核心系統，並迅速轉移到新系統的另一個光明的一面。
我支持這樣一個事實：一切離客戶和消費者更近的地方都是最大的商業利益和價值，其中適應性和對速度、變化、「嘗試、取消、重用、做不同的事情」的關注是最重要的。需要「——這就是景觀將發生變化的地方。 而且盒裝產品不太適合放在那裡。 至少我們沒有看到它。 那裡需要最簡單、最簡單的解決方案。
我們看到這樣的發展：
- 核心資訊系統（主要是後台）；
- 中間層以微服務的形式連接核心、聚合、創建快取等；
- 第一線系統針對的是消費者；
- 通常整合到市場、其他系統和生態系統中的整合層。 該層盡可能輕量、簡單，並且包含最少的業務邏輯。
但同時，如果使用得當，我支持繼續使用舊原則。
假設您有一個經典的企業系統。 它位於一個供應商的環境中，由兩個相互協作的模組組成。 還有一個標準的整合介面。 為什麼要重做並在那裡引入微服務？
但當後台有5個模組，將其中的資訊收集到業務流程中，然後供8-10個第一線系統使用時，好處立即顯而易見。 您從五個後台系統中獲取並創建一個服務，一個獨立的服務，專注於業務流程。 使服務在技術上先進 - 以便它可以快取資訊並具有容錯能力，並且還可以與文件或業務實體一起使用。 您可以根據單一原則將其與所有第一線產品整合。 他們取消了一線產品——他們只是關閉了整合。 明天您需要編寫一個行動應用程式或製作一個小型網站，並且只將一部分放入功能中 - 一切都很簡單：您像建構函數一樣組裝它。 我看到這個方向有更多的發展——至少在我們國家。
亞歷山大：
謝爾蓋完整地描述了我們的方法，謝謝。 我只想說我們絕對不會去的地方——核心部分，線上計費的主題。 也就是說，評級和收費實際上仍然是一個「大」脫粒機，可以可靠地沖銷資金。 而這個系統將繼續得到我們監管機構的認證。 當然，其他一切面向客戶的都是微服務。
德米特里：
這裡的認證只是一個故事。 應該會得到更多的支持吧。 如果你在支援上花費很少或系統不需要支援和修改，最好不要碰它。 合理的妥協。
如何開發可靠的微服務
德米特里：
美好的。 但我仍然感興趣。 現在你正在講述一個成功的故事：一切都很好，我們轉向微服務，向業務部門捍衛這個想法，然後一切都順利了。 但我還聽過其他故事。
幾年前，一家瑞士公司投資了兩年為銀行開發新的微服務平台，最終關閉了該專案。 徹底崩潰了。 花了數百萬瑞士法郎，最終團隊被解散——這沒有成功。
你有過類似的故事嗎？ 有沒有或現在有什麼困難？ 例如，維護微服務和監控也是公司營運活動中令人頭痛的問題。 畢竟元件數量增加了數十倍。 您怎麼看，這裡有投資不成功的例子嗎？ 您可以向人們提出什麼建議，以免他們遇到此類問題？
亞歷山大：
不成功的例子包括企業改變優先順序和取消專案。 當處於良好的準備階段時（事實上，MVP 已經準備好了），企業表示：“我們有新的優先事項，我們正在轉向另一個項目，我們正在關閉這個項目。”
我們的微服務沒有發生任何全域故障。 我們睡得很安穩，我們有 24/7 輪班，為整個 BSS [業務支援系統] 提供服務。
還有一件事 - 我們根據適用於盒裝產品的規則出租微服務。 成功的關鍵是，首先，您需要組建一個團隊，為生產做好充分的微服務準備。 開發本身是有條件的40%。 剩下的就是分析、DevSecOps 方法、正確的整合和正確的架構。 我們特別關注建立安全應用程式的原則。 資訊安全代表在架構規劃階段和實施過程中參與每個專案。 他們還管理用於分析程式碼漏洞的系統。
假設我們部署了無狀態服務 - 我們將它們放在 Kubernetes 中。 由於服務的自動擴展和自動提升，每個人都可以安然入睡，並且值班會發生事件。
在我們微服務的整個存在過程中，只有一兩個事件到達了我們的生產線。 現在操作已經沒有問題了。 當然，我們擁有的微服務不是 200 個，而是大約 50 個，但它們都用在旗艦產品中。 如果他們失敗了，我們將是第一個知道的人。
微服務和人力資源
謝爾蓋：
我同意我同事關於轉移到支援部門的觀點——工作需要正確組織。 但我會告訴你當然存在的問題。
首先，技術是新的。 這是一種很好的炒作，找到一位能夠理解並能夠創造這一點的專家是一個巨大的挑戰。 資源的競爭是瘋狂的，所以專家是有價值的。
其次，隨著某些景觀的打造和服務的不斷增多，重複利用的問題必須不斷解決。 正如開發人員喜歡做的那樣：「現在讓我們在這裡寫很多有趣的東西......」因此，系統會不斷增長，並在金錢、擁有成本等方面失去有效性。 也就是說，有必要將重複使用納入系統架構中，將其納入引入服務和將遺留系統轉移到新架構的路線圖中。
另一個問題是內部競爭，儘管這本身是件好事。 “哦，這裡出現了新的時尚人士，他們說一種新的語言。” 當然，人是不同的。 有些人習慣用 Java 編寫，有些人編寫並使用 Docker 和 Kubernetes。 他們是完全不同的人，他們說話方式不同，使用不同的術語，有時彼此無法理解。 能否分享實踐、分享知識，從這個意義上也是一個問題。
好吧，擴展資源。 「太好了，我們走吧！ 現在我們想要更快、更多。 什麼，你不能？ 一年交貨量不是可以翻倍嗎？ 為什麼？” 這種成長的煩惱可能是很多事情、很多方法的標準，你可以感覺到它們。
關於監控。 在我看來，服務或工業監控工具已經在學習或能夠以不同的非標準模式與 Docker 和 Kubernetes 一起工作。 因此，舉例來說，您最終不會擁有 500 台 Java 機器來運行所有這些，即聚合。 但這些產品還不夠成熟，必須經歷這個過程。 這個話題確實很新，它會繼續發展。
德米特里：
是的，非常有趣。 這也適用於人力資源。 也許您的人力資源流程和人力資源品牌在這三年中發生了一些變化。 你開始招募其他具有不同能力的人。 可能有利也有弊。 此前，區塊鏈和數據科學被炒作，這些領域的專家身價數百萬美元。 現在成本在下降，市場正在趨於飽和，微服務也有類似的趨勢。
謝爾蓋：
是的，一點沒錯。
亞歷山大：
HR 提出問題：“你的粉紅色獨角獸在後端和前端之間在哪裡？” HR 不明白什麼是微服務。 我們告訴他們這個秘密，並告訴他們後端做了一切，並且沒有獨角獸。 但人力資源部門正在發生變化，快速學習並招募具有基本 IT 知識的人員。
微服務的演變
德米特里：
如果你看看目標架構，微服務看起來就像怪物。 你的旅程花了幾年時間。 有的人一年，有的人三年。 您是否預見了所有問題、目標架構，有什麼改變嗎？ 例如，就微服務而言，網關和服務網格現在再次出現。 您是一開始就使用它們還是更改了架構本身？ 你有這樣的挑戰嗎？
謝爾蓋：
我們已經重寫了幾個通訊協定。 起初有一個協議，現在我們改用另一個協議。 我們提高安全性和可靠性。 我們從企業技術開始 - Oracle、Web Logic。 現在，我們正在從微服務中的技術企業產品轉向開源或完全開放的技術。 我們放棄資料庫，轉向在這個模型中對我們更有效的方法。 我們不再需要 Oracle 技術。
我們一開始只是簡單地作為一個服務，沒有考慮我們需要多少緩存，當沒有與微服務連接但需要數據時我們會做什麼等等。現在我們正在開發一個平台，以便可以描述架構不是用服務語言，而是用業務語言，當我們開始用語言交談時，將業務邏輯提升到一個新的水平。 現在我們已經學會了用字母說話，下一個層次是服務將被收集到某種聚合中，此時這已經是一個單字 - 例如，整個產品卡。 它是由微服務組裝而成，但它是建立在其之上的 API。
安全非常重要。 一旦你開始變得容易訪問，並且你擁有一項服務，透過它你可以很快地、在一瞬間獲得很多有趣的東西，那麼就會渴望以一種不是最安全的方式獲得它。 為了避免這種情況，我們必須改變測試和監控的方法。 我們必須改變團隊、交付管理結構、CI/CD。
這是一種演變——就像電話一樣，只是速度更快：首先出現了按鈕式電話，然後出現了智慧型手機。 由於市場有不同的需求，他們重寫並重新設計了產品。 這就是我們的發展方式：一年級，十年級，工作。
迭代地，每年從技術的角度佈局一些東西，從積壓和需求的角度佈局一些東西。 我們將一件事與另一件事聯繫起來。 團隊花費 20% 用於團隊的技術債和技術支援，80% 用於業務實體。 我們在行動時了解為什麼要這樣做，為什麼我們要進行這些技術改進，以及它們會帶來什麼。 像那樣。
德米特里：
涼爽的。 MegaFon 中有什麼？
亞歷山大：
當我們接觸微服務時，主要的挑戰是不要陷入混亂。 MegaFon的架構辦公室立即加入了我們，甚至成為了發起者和推動者——現在我們有了一個非常強大的架構。 他的任務是了解我們要採用什麼目標模型以及需要試行哪些技術。 對於建築，我們自己進行了這些試點。
下一個問題是：“那麼如何利用這一切？” 還有一個問題：“如何確保微服務之間的透明互動？” 服務網格幫助我們回答了最後一個問題。 我們試用了 Istio 並且喜歡結果。 現在我們正處於向生產區推廣的階段。 我們對所有挑戰都抱持著正面的態度——事實上，我們需要不斷改變堆棧，學習新的東西。 我們感興趣的是開發而不是利用舊的解決方案。
德米特里：
金字！ 這些挑戰讓團隊和業務保持警惕並創造未來。 GDPR 設立了首席資料保護官，而當前的挑戰則設立了首席微服務和架構官。 這很令人高興。
我們討論了很多。 最重要的是，良好的微服務設計和架構本身可以讓你避免許多錯誤。 當然，這個過程是迭代和進化的，但這就是未來。
感謝所有參與者，感謝謝爾蓋和亞歷山大！
觀眾提問
觀眾提問（1）：
Sergey，您公司的 IT 管理發生了什麼樣的變化？ 我知道，當有多個系統組成的大堆疊時，如何管理它是一個相當清晰且合乎邏輯的過程。 在這麼短的時間內整合了大量的微服務之後，你們是如何重建IT元件的管理的？
謝爾蓋：
我同意我同事的觀點，即架構作為變革的驅動力非常重要。 我們首先成立了一個建築部門。 建築師同時也是功能分配和功能在景觀中如何出現的要求的所有者。 因此他們也充當這些變革的協調者。 因此，當我們建立 CI/CD 平台時，對特定的交付流程進行了特定的變更。
但標準、開發基本原則、業務分析、測試和開發並沒有取消。 我們只是增加了速度。 以前，週期花費了很多時間，在測試環境中安裝也花了更多時間。 現在，企業看到了好處，並說：“為什麼我們不能在其他地方做同樣的事情？”
從好的方面來說，這就像以疫苗的形式進行注射，表明：你可以用這種方式做到這一點，但你也可以用另一種方式做到這一點。 當然，人員上有問題，能力上有問題，知識上有問題，抵抗力上有問題。
觀眾提問（2）：
微服務架構的批評者表示測試和開發很困難。 當事情變得複雜時，這是合乎邏輯的。 您的團隊面臨哪些挑戰以及您是如何克服這些挑戰的？ 向大家提問。
亞歷山大：
從微服務遷移到平台時會遇到一些困難，但這些困難是可以解決的。
例如，我們正在製作一個由 5-7 個微服務組成的產品。 我們需要在整個微服務堆疊中提供整合測試，以便為遷移到主分支開綠燈。 這項任務對我們來說並不新鮮：我們在 BSS 已經這樣做了很長時間，當時供應商為我們提供了已經發貨的解決方案。
而我們的問題只出在小團隊。 一款有條件的產品需要一名 QA 工程師。 因此，我們推出了包含 5-7 個微服務的產品，其中 2-3 個可以由第三方開發。 例如，我們的計費系統供應商 Mail.ru Group 和 MegaFon R&D 參與了一款產品的開發。 在將其投入生產之前，我們需要對其進行測試。 QA 工程師已經在這個產品上工作了一個半月，而團隊的其他成員卻失去了他的支持。
這種複雜性只是由縮放引起的。 我們知道微服務不可能存在於真空中；絕對的隔離是不存在的。 當更改一項服務時，我們總是嘗試保留 API 契約。 如果引擎蓋下發生了變化，前台服務仍然保留。 如果變化是致命的，就會發生某種架構轉換，我們會轉向完全不同的資料元模型，這是完全不相容的——只有那時我們才談論 v2 服務 API 規範的出現。 我們同時支援第一個和第二個版本，當所有消費者切換到第二個版本後，我們只需關閉第一個版本即可。
謝爾蓋：
我想補充一下。 我完全同意併發症的說法——它們確實會發生。 情況變得越來越複雜，管理成本也在增加，尤其是測試成本。 如何處理這個問題：切換到自動化測試。 是的，您必須額外投資編寫自動測試和單元測試。 這樣開發人員就無法在未通過測試的情況下提交，也無法更改程式碼。 因此，如果沒有自動測試、單元測試，即使按鈕也無法運作。
維護以前的功能很重要，這是額外的開銷。 如果您將一項技術重寫為另一種協議，那麼您將重寫它，直到完全關閉所有內容。
我們有時不會故意進行端到端測試，因為我們不想停止開發，儘管我們也有一件又一件的事情。 景觀非常大、複雜，有許多系統。 有時這只是存根 - 是的，你降低了安全裕度，就會出現更多風險。 但同時你釋放了供應。
亞歷山大：
是的，自動測試和單元測試可讓您創建高品質的服務。 我們支援沒有單元和整合測試就無法通過的管道。 我們常常要把模擬器和商業系統拖曳到測試區和開發環境中，因為並不是所有的系統都可以放在測試區。 此外，它們不僅會被弄濕，我們還會從系統中產生完整的響應。 這是微服務工作的重要部分，我們也對此進行投資。 如果沒有這個，就會出現混亂。
觀眾提問（3）：
據我了解，微服務最初是由一個單獨的團隊發展而來，現在存在於這個模型中。 它的優點和缺點是什麼？
我們有一個類似的故事：一種微服務工廠的出現。 現在，我們在概念上已經達到了這樣的程度：我們正在將這種方法擴展到透過流和系統進行生產。 換句話說，我們正在遠離微服務、微服務模型的中心化開發，而越來越接近系統。
相應地，我們的操作也走向了系統，就是說我們正在去中心化這個主題。 你的方法是什麼？你的目標故事是什麼？
亞歷山大：
你直接從嘴裡說出了「微服務工廠」這個名字——我們也想擴大規模。 首先，我們現在確實擁有了一支球隊。 我們希望為 MegaFon 的所有開發團隊提供在共同生態系統中工作的機會。 我們不想完全接管我們現在擁有的所有開發功能。 局部任務是擴展，全域任務是領導微服務層所有團隊的開發。
謝爾蓋：
我會告訴你我們走過的路。 我們真正開始作為一個團隊工作，但現在我們並不孤單。 我是以下觀點的支持者：流程必須有一個所有者。 需要有人理解、管理、控制和建構微服務開發流程。 他必須擁有資源並參與資源管理。
這些了解技術、細節並了解如何建立微服務的資源可以位於產品團隊中。 我們有一個組合，來自微服務平台的人員加入了製作行動應用程式的產品團隊。 他們在那裡，但是他們按照微服務平台管理部門的流程和他們的開發經理一起工作。 該部門內有一個單獨的團隊負責技術處理。 也就是說，我們將我們之間的公共資源混合起來，然後將它們劃分給團隊。
同時，該過程仍然是通用的、受控的，它根據通用技術原理進行，並進行單元測試等等——一切都建立在之上。 可能會有專欄的形式收集來自不同部門的產品方法的資源。
亞歷山大：
Sergey，您實際上是流程的擁有者，對嗎？ 任務積壓是否共享？ 誰負責其分配？
謝爾蓋：
看：這又是混音。 由於技術改進而形成了積壓的訂單——這是一個故事。 有一個積壓訂單，它是由項目制定的，還有一個積壓訂單來自產品。 但是引入每個服務產品或創建該服務的順序是由產品專家製定的。 他不在 IT 部門；他是被特意調離的。 但我的員工肯定是按照同樣的流程工作的。
不同方向的積壓工作（變更積壓工作）的所有者將是不同的人。 技術服務的連接及其組織原則 - 所有這些都將在 IT 中實現。 我也擁有這個平台和資源。 最上面的是積壓和功能變更以及這個意義上的架構。
假設一家企業說：“我們想要這個功能，我們想要創建一個新產品——重新發放貸款。” 我們回答：“是的，我們會重做。” 架構師說：“讓我們想一想：我們將在貸款的哪個位置編寫微服務以及如何實現？” 然後我們將其分解為專案、產品或技術堆疊，將其放入團隊並實施。 您是否在內部創建了一個產品並決定在該產品中使用微服務？ 我們說：“現在我們擁有的遺留系統或一線系統必須切換到這些微服務。” 架構師說：「所以：在一線產品內部的技術積壓中－向微服務的過渡。 去」。 產品專家或企業主了解分配了多少容量、何時完成以及原因。
討論結束，但還沒結束
mailto:CLOUD 會議召開 .
我們也舉辦其他活動 - 例如 @Kubernetes 聚會，我們一直在尋找優秀的演講者：
- 在我們的 Telegram 頻道中關注 @Kubernetes 和其他 @Meetup 新聞
- 有興趣在 @Meetups 之一上發表演講嗎？ 留下請求
來源： www.habr.com