Banki.ru 入口網站營運總監 Andrey Nikolsky 在去年的會議上發表了講話 關於孤立服務：如何識別基礎設施中的孤立服務、為什麼孤立服務不好、如何處理它們以及如果沒有任何幫助該怎麼辦。
剪輯下方是報告的文字版本。
同事們大家好！我叫安德烈 (Andrey)，負責 Banki.ru 的營運。
我們有大型服務，這些都是單一的服務，有更經典意義上的服務，也有非常小的服務。用我工農的術語來說，如果一個服務簡單、小，那麼它就是微的，如果它不是很簡單、小，那麼它就是一個服務。
服務優點
我將快速介紹這些服務的優勢。
首先是縮放。您可以快速在服務上做一些事情並開始生產。你已經收到了流量，你已經克隆了服務。你有更多的流量，你已經克隆了它並接受它。這是一個很好的獎勵，原則上，當我們開始時，它被認為對我們來說是最重要的事情，為什麼我們要做這一切。
其次，隔離開發，當你有多個開發團隊，每個團隊中有幾個不同的開發人員，並且每個團隊開發自己的服務。
對於團隊來說，存在細微差別。開發商不一樣。還有，例如， 。我第一次看到這個是和馬克西姆·多洛費耶夫（Maxim Dorofeev）一起。有時雪花人在某些團隊中而不在其他團隊中。這使得整個公司使用的不同服務有點參差不齊。
看圖：這是一個很好的開發者，他有一雙大手，他能做很多事。主要問題是這些手從哪裡來。
服務使得使用更適合不同任務的不同程式語言成為可能。有些服務是用 Go 寫的，有些是用 Erlang 寫的，有些是用 Ruby 寫的，有些是用 PHP 寫的，有些是用 Python 寫的。一般來說，你可以非常廣泛地擴展。這裡也存在細微差別。
以服務為導向的架構主要是關於 DevOps。也就是說，如果你沒有自動化，就沒有部署過程，如果你手動配置它，你的配置可以從一個服務實例更改到另一個實例，你必須去那裡做一些事情，那麼你就陷入了地獄。
例如，你有20個服務，你需要手動部署，你有20個控制台，你像忍者一樣同時按下「回車」。這不太好。
如果您在測試後有一個服務（當然，如果有測試的話），並且您仍然需要用一個文件來完成它，以便它在生產中工作，我也有壞消息要告訴您。
如果你依賴特定的亞馬遜服務並在俄羅斯工作，那麼兩個月前你也會有“周圍的一切都著火了，我很好，一切都很酷。”
我們使用 Ansible 來自動化部署，使用 Puppet 來實現整合，使用 Bamboo 來自動化部署，並使用 Confluence 以某種方式描述這一切。
我不會詳細討論這個，因為報告更多的是互動實踐，而不是技術實現。
例如，我們遇到過這樣的問題：伺服器上的 Puppet 可以與 Ruby 2 一起使用，但某些應用程式是為 Ruby 1.8 編寫的，而且它們不能一起工作。那裡出了問題。當您需要在一台機器上執行多個版本的 Ruby 時，通常會開始遇到問題。
例如，我們給每個開發人員一個平台，上面幾乎有我們擁有的一切，所有可以開發的服務，這樣他就有一個隔離的環境，他可以打破它並按照他想要的方式建立它。
碰巧您需要一些專門編譯的軟體包來支援那裡的某些東西。這是相當艱難的。我聽過一篇報導 Docker 映像有 45 GB。當然，在 Linux 中，它更簡單，一切都更小，但仍然沒有足夠的空間。
嗯，存在衝突的依賴關係，當專案的一部分依賴於一個版本的庫時，專案的另一部分依賴另一個版本，而這些庫根本不安裝在一起。
我們在 PHP 5.6 中有網站和服務，我們為它們感到羞恥，但我們能做什麼呢？這是我們唯一的網站。 PHP 7 上有網站和服務，還有更多，我們並不以此為恥。每個開發者都有自己的基地，他樂於看到那裡。
如果您在公司中使用一種語言進行編寫，那麼每個開發人員擁有三個虛擬機器聽起來很正常。如果您使用不同的程式語言，那麼情況會變得更糟。
你在這上面有站點和服務，然後是另一個 Go 站點，一個 Ruby 站點，還有其他一些 Redis 站點。結果，所有這一切都變成了一個巨大的支撐場，並且總是有一些可能會被打破。
因此，我們用不同的框架取代了程式語言的好處，因為PHP框架有很大不同，它們有不同的功能、不同的社群和不同的支援。您可以編寫一個服務，這樣您就已經準備好了一些東西。
每個服務都有自己的團隊
我們多年來的主要優勢是每個服務都有自己的團隊。這對於大型專案來說很方便，可以節省文件時間，經理非常了解他們的專案。
您可以輕鬆地從支援人員提交任務。例如，保險服務故障。處理保險的團隊立即去修復它。
新功能正在快速創建，因為當您擁有原子服務時，您可以快速將某些內容添加到其中。
當你破壞你的服務時，這種情況不可避免地發生，你並沒有影響其他人的服務，其他團隊的開發人員也不會拿著比特跑來告訴你：“哎呀，不要這樣做。”
一如既往，存在細微差別。我們有穩定的團隊，管理者是固定在團隊中的。有明確的文件，管理者密切監控一切。每個擁有經理的團隊都有多項服務，並且有特定的能力點。
如果團隊是浮動的（我們有時也使用這個），有一個很好的方法，稱為「星圖」。
您有一份服務和人員清單。星號表示該人是該服務的專家，書籍表示該人正在研究該服務。該人的任務是將小冊子改為星號。如果服務前面沒有寫任何內容，那麼就會出現問題，我將進一步討論這一點。
孤兒服務如何出現？
第一個問題，在基礎設施中獲得孤立服務的第一種方法是解僱人員。有沒有人曾經讓企業在評估任務前準時完成任務？有時，期限很緊，根本沒有足夠的時間來記錄文件。 “我們需要將服務移交給生產，然後再添加它。”
如果團隊規模很小，那麼很可能只有一位開發人員編寫所有內容，其他人則在幕後工作。 “我寫了基本架構，讓我們添加介面。”然後在某個時候，經理就會離開。在此期間，當經理離開並且尚未任命新經理時，開發人員自己決定服務的走向以及那裡發生的事情。正如我們所知（讓我們回顧幾張幻燈片），在一些團隊中有雪花人，有時還有雪花團隊領導。然後他辭職了，我們得到了孤兒服務。
同時，來自支援和業務的任務並沒有消失；它們最終會積壓。如果在服務開發過程中出現任何架構錯誤，它們也會被積壓。服務正在慢慢惡化。
如何認定孤兒身分？
這份清單很好地描述了這種情況。誰了解了他們的基礎設施？
關於已記錄的解決方法：有一項服務，一般來說，它可以工作，它有一本兩頁的手冊，介紹如何使用它，但沒有人知道它內部是如何工作的。
或者，例如，有某種鏈結縮短器。例如，我們目前在不同的服務中出於不同的目的使用了三種連結縮短器。這些只是後果。
現在我將成為顯而易見的隊長。應該做什麼？首先，我們需要將服務轉移給另一個經理、另一個團隊。如果您的團隊領導尚未退出，那麼在另一個團隊中，當您了解該服務就像孤兒時，您需要包括至少了解一些相關資訊的人。
最重要的是：你必須有血寫的轉移程序。就我們而言，我通常會監控這一點，因為我需要它一切正常工作。管理者需要快速交付，之後發生的事對他們來說不再那麼重要。
下一個製作孤兒的方法是“我們將其外包，會更快，然後我們將其交給團隊。”很明顯，團隊裡每個人都有一些計劃，輪流轉。通常，企業客戶認為外包商會做與公司技術部門相同的事情。儘管他們的動機不同。外包有奇怪的技術解決方案和奇怪的演算法解決方案。
例如，我們有一項服務，在各種意想不到的地方都有獅身人面像。我稍後會告訴你我必須做什麼。
外包商有自己寫的框架。這只是從以前的專案複製貼上的裸 PHP，您可以在其中找到各種各樣的東西。當您需要使用一些複雜的 Bash 腳本來更改某些檔案中的多行並且這些部署腳本由某些第三個腳本呼叫時，部署腳本是一個很大的缺點。結果，你改變了部署系統，選擇了其他東西，跳了，但你的服務不起作用。因為有必要在不同資料夾之間再放置 8 個連結。或者碰巧有一千筆記錄有效，但十萬筆記錄不再有效。
我將繼續擔任隊長。接受外包服務是強制性程序。有沒有人遇過外包服務到達後卻未被任何地方接受的經驗？當然，這不像孤兒服務那麼受歡迎，但仍然如此。
服務需要檢查，服務需要審核，密碼需要更改。我們有一個案例，當他們給我們服務時，有一個管理面板“if login == 'admin' && password == 'admin'...”，它就寫在程式碼中。我們坐下來思考，人們在 2018 年寫下這篇文章？
測試儲存容量也是必要的事情。即使在將此服務投入生產之前，您也需要了解十萬筆記錄會發生什麼。
發送服務進行改進應該沒有什麼可恥的。當你說：“我們不會接受這項服務，我們有 20 個任務，完成它們，然後我們就會接受”，這是正常的。您的良心不應該因為您正在設立經理或企業在浪費金錢而受到傷害。然後企業將花費更多。
當我們決定外包一個試點專案時，我們遇到了一個案例。
按時交付，這是唯一的品質標準。這就是為什麼我們做了另一個試點項目，它甚至不再是一個真正的試點項目。這些服務被接受了，他們透過行政手段說，這是你的程式碼，這是團隊，這是你的經理。這些服務實際上已經開始獲利。同時，事實上，他們仍然是孤兒，沒有人理解他們是如何工作的，管理者也盡力否認他們的任務。
還有一個偉大的理念－遊擊式發展。當某個部門（通常是行銷部門）想要檢驗一個假設並訂購整個服務外包。流量開始流向它，他們關閉文件，與承包商簽署文件，開始運營並說：“夥計們，我們這裡有一項服務，它已經有了流量，它給我們帶來了錢，讓我們接受它。”我們當時就想，“Oppa，怎麼會這樣。”
還有另一種獲得孤兒服務的方法：當某個團隊突然發現自己負載過重時，管理層會說：“讓我們將該團隊的服務轉移到另一個團隊，它的負載較小。”然後我們會將其轉移到第三支球隊並更換經理。最後我們又有了一個孤兒。
孤兒有什麼問題？
誰不知道，這就是瑞典培養的瓦薩號戰艦，以下水5分鐘就沉沒聞名。順便說一句，瑞典國王並沒有因此處決任何人。它是由兩代不知道如何建造這種船的工程師建造的。效果自然。
順便說一句，這艘船可能會以更糟糕的方式沉沒，例如，當國王已經在暴風雨中的某個地方乘坐它時。所以，他立刻就被淹死了，根據敏捷的說法，儘早失敗是件好事。
如果我們儘早失敗，通常不會有任何問題。例如，在驗收期間將其發送以進行修改。但如果我們在生產上已經失敗，當資金投入時，那麼可能就會出現問題。後果，正如商業上所說的。
為什麼孤兒服務很危險：
- 服務可能會突然中斷。
- 該服務需要很長時間才能修復或根本無法修復。
- 安全問題。
- 改進和更新問題。
- 如果一項重要服務發生故障，公司的聲譽就會受到損害。
孤兒服務該怎麼辦？
我將再次重複該做什麼。首先，必須有文件。在 Banki.ru 工作的 7 年告訴我，測試人員不應該相信開發人員的話，營運也不應該相信每個人的說法。我們需要檢查一下。
其次，有必要寫一篇互動圖，因為有些較不受歡迎的服務往往包含無人提及的依賴關係。例如，開發人員在某些 Yandex.Maps 或 Dadata 的金鑰上安裝了該服務。你已經用完了免費限制，一切都壞了，你根本不知道發生了什麼事。所有這些耙子都必須被描述：該服務使用數據、簡訊或其他東西。
第三，處理技術債。當你拄著拐杖或接受服務並說需要做某事時，你需要確保它已經完成。因為那樣的話可能會發現這個小洞並沒有那麼小，你會從裡面掉下去。
在建築任務中，我們有一個關於獅身人面像的故事。其中一項服務使用 Sphinx 來輸入清單。只是一個分頁列表，但每天晚上都會重新索引。它由兩個索引組裝而成：一個大索引每天晚上都會索引，還有一個小索引用螺絲固定在上面。每天，有50%的機率，無論是否被炸，指數在計算過程中崩潰，我們的新聞在主頁上停止更新。起初，索引需要 5 分鐘才能重新建立索引，然後索引不斷增長，在某個時刻開始需要 40 分鐘才能重新建立索引。當我們刪除這個時，我們鬆了一口氣，因為很明顯，還需要一點時間，我們的索引將完全重新索引。這對我們的門戶來說將是一個失敗，八個小時沒有消息——就這樣，業務停止了。
與孤兒服務合作的計劃
其實這是很難做到的，因為devops就是溝通。你想與同事搞好關係，當你用規章打擊同事和經理時，他們可能會對這樣做的人產生矛盾的感覺。
除了所有這些點之外，還有另一件事很重要：特定的人必須負責每個特定的服務、部署流程的每個特定部分。當沒有人的時候，你必須吸引其他人來研究整件事，這就變得很困難。
如果所有這些都沒有幫助，並且您的孤立服務仍然是孤立的，沒有人願意接受它，沒有編寫文檔，被召集到該服務的團隊拒絕做任何事情，有一個簡單的方法 - 重做一切 。
也就是說，您重新提出服務需求，並在更好的平台上編寫更好的新服務，而無需奇怪的技術解決方案。你會在戰鬥中遷移到它。
我們遇到過這樣的情況，當我們在Yii 1 上使用一個服務時，我們意識到我們無法進一步開發它，因為我們已經沒有能夠在Yii 1 上寫得好的開發人員了。所有開發人員都在Symfony XNUMX 上寫得很好。怎麼辦？我們分配時間、分配團隊、分配經理、重寫專案並順利切換流量。
此後，可以刪除舊服務。這是我最喜歡的過程，當您需要從配置管理系統中取出並清除某些服務，然後查看並看到所有生產中的汽車都已被禁用，以便開發人員不會留下任何痕跡。存儲庫保留在 Git 中。
這就是我想談的一切，我準備討論了，話題是holivar，很多人都在其中游泳。
幻燈片說你們統一了語言。一個例子是調整圖片的大小。真的有必要嚴格限制為一種語言嗎？因為在 PHP 中調整圖片大小實際上可以在 Golang 中完成。
事實上，就像所有實踐一樣，它是可選的。也許，在某些情況下，這甚至是不可取的。但你需要明白，如果你的公司有一個 50 人的技術部門，其中 45 人是 PHP 專家，另外 3 人是懂 Python、Ansible、Puppet 之類的開發人員，而且只有一個人會寫一些東西。某種語言。一些Go 圖像大小調整服務，然後當它離開時，專業知識也隨之消失。同時，您需要尋找了解這種語言的特定市場開發人員，尤其是在這種語言很少見的情況下。也就是說，從組織的角度來看，這是有問題的。從 DevOps 的角度來看，您不僅需要複製一些用於部署服務的現成的劇本集，而且還必須重新編寫它們。
我們目前正在 Node.js 上建立一項服務，這將只是每個使用單獨語言的開發人員附近的平台。但我們坐下來認為這場比賽得不償失。也就是說，這裡有一個問題讓你坐下來思考。
您如何監控您的服務？您如何收集和監控日誌？
我們在Elasticsearch中收集日誌並將其放入Kibana中，根據是生產環境還是測試環境，在那裡使用不同的收集器。我不記得在某個地方伐木工，在其他地方還有其他東西。而且在某些服務中仍然有一些地方我們安裝了 Telegraf，並在其他地方單獨拍攝。
如何在同一環境中與 Puppet 和 Ansible 共存？
其實我們現在有兩個環境，一個是Puppet，一個是Ansible。我們正在努力將它們雜交。 Ansible 是一個很好的初始設定框架，Puppet 是一個糟糕的初始設定框架，因為它需要直接在平台上進行實際操作，而 Puppet 可確保設定收斂。這意味著平台會保持自身處於最新狀態，為了讓 ansibilized 機器保持最新狀態，您需要始終以一定頻率在其上執行 playbook。這就是差別。
如何保持相容性？您在 Ansible 和 Puppet 中都有設定嗎？
這是我們的巨大痛苦，我們保持與雙手的兼容性，並思考如何從現在的這一切中繼續前進。事實證明，Puppet 在那裡推出軟體包並維護一些鏈接，而 Ansible 則在那裡推出程式碼並調整最新的應用程式配置。
該演示涉及 Ruby 的不同版本。什麼解決辦法？
我們在一個地方遇到過這種情況，而且我們必須一直把它記在心裡。我們只是關閉了在 Ruby 上運行的與應用程式不相容的部分，並將其分開。
今年的會議 將於 7 月 11 日在 Technopolis 舉行。 我們在 XNUMX 月 XNUMX 日之前接受報告申請。 如果您想發言，請聯絡我們。
參與者報名現已開放，加入我們吧！
來源： www.habr.com