巧合是隨機的，而且確實是在另一個星球上......
我想分享三個有關後端開發人員如何與管理員團隊合作的成功和失敗的故事。
歷史第一。
網絡工作室，員工數量一隻手就能數過來。 今天你是一名程序員，明天你是一名後端人員，後天你是一名管理員。 一方面，你可以獲得豐富的體驗。 另一方面，各個領域都缺乏能力。 還記得第一個工作日，我還是青澀的，老闆說：“開膩子”，但我不知道那是什麼。 與管理員的溝通被排除在外，因為。 你是管理員。 考慮這個職位的利弊。
+ 所有的權力都在你的手中。
+ 無需請求任何人從服務器訪問。
+ 全面快速的反應時間。
+ 井泵技能。
+ 對產品架構有完整的了解。
- 高度責任感。
- 中斷生產的風險。
— 成為所有領域的優秀專家是很困難的。
不感興趣，我們繼續吧。
第二個故事。
大公司，大項目。 有一個行政部門，有5-7名員工和幾個開發團隊。 當你來到這樣的公司工作時，每個管理員都會認為你來這裡不是為了開發產品，而是為了破壞某些東西。 簽署的保密協議和麵試時的選擇都沒有說明其他情況。 不，這個男人用他的髒手來這裡破壞我們的接吻表演。 因此，和這樣的人你需要最少的溝通，你可以極端地貼個貼紙作為回應。 不要回答有關項目架構的問題。 建議在團隊領導提出要求之前不要授予訪問權限。 當被要求時，發出比要求的權限更少的權限。 幾乎所有與此類管理員的溝通都被開發部門和管理部門之間的黑洞所吞噬。 問題無法快速解決。 而且您無法親自接近 - 管理員 24/7 太忙了。 （你一直在做什麼？）一些性能特徵：
- 平均部署到生產時間 4-5 小時
- 生產的最長部署時間 9 小時
- 對於開發人員來說，生產中的應用程序是一個黑匣子，就像生產服務器本身一樣。 一般有多少人？
- 發布質量差，錯誤頻繁
- 開發者不參與發布過程
好吧，我期待什麼，當然，新人不被允許進入生產。 好吧，只要有耐心，我們就開始贏得別人的信任。 但出於某種原因，對於管理員來說事情並不那麼簡單。
行為 1. 管理員是不可見的。
發布當天，開發者和管理員不溝通。 管理員沒有問題。 但為什麼後來才明白。 管理員是一個有原則的人，沒有即時通訊工具，不會向任何人提供電話號碼，在社交網絡中沒有個人資料。 是的，連他的照片都沒有，你看起來怎麼樣，伙計？ 我們困惑地與負責經理坐了大約 15 分鐘，試圖與這架 Voyager 1 建立聯繫，然後一條消息落在他已經完成的公司郵件中。 我們要通過郵件通信嗎？ 為什麼不？ 方便不是嗎？ 好吧，讓我們冷靜一下。 這個過程已經在進行中，沒有回頭路。 我們再次閱讀了該消息。 “我完成了”。 你完成了什麼？ 在哪裡？ 去哪裡找你呢？ 到這裡你就明白為什麼每次發布4小時是正常的了。 我們對開發感到震驚，但我們完成了發布。 再也沒有想要釋放的慾望了。
第 2 步。版本錯誤。
下一個版本。 獲得經驗後，我們開始為管理員制定服務器所需的軟件和庫列表，並指出一些版本。 與往常一樣，我們收到微弱的無線電信號，表明管理員已在那裡完成了某些操作。 回歸測試開始，這本身需要大約一個小時。 一切似乎都正常，但有一個嚴重的錯誤。 重要功能無法使用。 接下來的幾個小時是敲手鼓跳舞、在咖啡渣上占卜、詳細審查每一段代碼。 管理員說他做到了。 krivorukovy 開發人員編寫的應用程序無法運行，而服務器可以運行。 他有什麼問題。 幾個小時後，我們仍然讓管理員將庫的版本放到生產服務器上，然後將其放入聊天中 - 這不是我們所需要的。 我們要求管理員安裝所需的版本，但我們得到的答復是，由於操作系統包管理器中沒有該版本，因此他無法執行此操作。 在這裡，經理從記憶庫中回憶起另一個管理員已經解決了這個問題，只需用手收集所需的版本即可。 但不，我們不會那樣做。 規定禁止。 卡爾，我們已經坐了好幾個小時了，有什麼規定嗎？！ 我們再次感到震驚，發布不知何故已經結束。
第三幕，簡短
緊急票據，關鍵功能對生產中的用戶之一不起作用。 戳幾個小時，檢查一下。 在開發環境中，一切正常。 有一個清晰的認識，那就是查看 php-fpm 日誌會很好。 當時項目上還沒有像 ELK 或 Prometheus 這樣的日誌系統。 我們向管理部門開一張票，以便他們可以訪問服務器的 php-fpm 日誌。 在這裡你需要明白，我們並不輕易要求訪問，你還記得黑洞和管理員 24/7 的忙碌嗎？ 如果你讓他們自己看日誌，那麼這就是一個優先級為“今生不會”的任務。 票證創建後，我們立即得到了管理部門負責人的回复：“您不應該需要訪問生產中的日誌，編寫沒有錯誤。” 一個窗簾。
第四幕及以後
由於庫版本不同、軟件未配置、服務器負載未做好準備以及其他問題，我們正在收集更多生產中的問題。 當然，代碼錯誤也會發生，我們不會把所有的罪過都歸咎於管理員，我們只會提到該項目的一個更典型的操作。 我們有很多後台工作人員是通過主管啟動的，並且必須將一些腳本添加到 cron 中。 有時這些工人停止工作。 在隊列服務器上，負載以閃電般的速度增長，悲傷的用戶看著旋轉的裝載機。 為了快速修復，只需重新啟動這些工作人員就足夠了，但同樣，只有管理員才能執行此操作。 這麼簡單的手術，一整天就過去了。 當然，在這裡，值得注意的是，不誠實的程序員應該編寫工人，以便他們不會跌倒，但是當他們跌倒時，最好理解為什麼，當然，由於缺乏生產訪問權限，這有時是不可能的，因此缺乏開發者日誌。
轉變。
在經歷了相當長一段時間的這一切之後，我們和團隊一起開始朝著更成功的方向前進。 總而言之，我們面臨哪些挑戰？
- 開發商與行政部門之間缺乏高質量的溝通
- 事實證明（！），管理員根本不了解應用程序如何工作、它有哪些依賴項以及它如何工作。
- 開發人員不了解生產環境如何工作，因此無法有效響應問題。
- 部署過程花費的時間太長。
- 版本不穩定。
我們做了什麼？
對於每個版本，都會形成一份發行說明列表，其中包括下一個版本正常運行時需要在服務器上完成的工作列表。 該列表包含幾個部分，即負責發布的管理員和開發人員必須完成的工作。 開發人員可以訪問（而不是 root）所有生產服務器，這總體上加速了開發，特別是解決問題。 此外，開發人員還了解了生產的運作方式、它分為哪些服務、副本的成本和成本。 從某種程度上來說，戰鬥負載變得更加容易理解，這無疑影響了代碼的質量。 發布過程中的交流是在其中一位使者的聊天中進行的。 首先，我們有所有行動的日誌，其次，溝通是在更緊密的環境中進行的。 擁有不止一次的行動歷史可以讓新員工更快地解決問題。 這是一個悖論，但這通常對管理員本身有幫助。 我不敢肯定地說，但在我看來，管理員已經開始更多地了解該項目是如何運作的，以及它是如何編寫的。 有時我們甚至會互相分享一些細節。 平均發佈時間縮短至一個小時。 有時我們會花30-40分鐘。 bug 的數量減少了數倍，甚至數十倍。 當然，其他因素也導致了發佈時間的縮短，例如自動測試。 每次發布後，我們都開始進行回顧。 讓整個團隊了解什麼是新的、什麼是改變的、什麼是被刪除的。 不幸的是，管理員並不總是來找他們，好吧，管理員很忙......作為一名開發人員，我的工作滿意度無疑增加了。 當你能夠快速解決你能力範圍內的幾乎所有問題時，你會感覺自己像一匹馬。 後來，我會意識到我們在某種程度上引入了 DevOps 文化，當然不是完全，但即使是轉型的開始也令人印象深刻。
故事三
啟動。 一名管理員，一個小型開發部門。 抵達後，我完全是零，因為除了郵件訪問之外我無處可去。 我們寫信給管理員，請求授予訪問權限。 此外，有信息表明他知道新員工以及需要提供登錄名/密碼。 他們提供從存儲庫和 VPN 的訪問。 為什麼要授予對 wiki、teamcity、rundesk 的訪問權限？ 對於一個被叫去寫整個後端部分的人來說毫無用處。 只有隨著時間的推移，我們才能使用一些工具。 當然，他的到來引起了人們的懷疑。 我試圖通過聊天和引導性問題慢慢摸索項目基礎設施是如何運作的。 基本上我什麼都不知道。 生產與以前一樣是黑匣子。 但不僅如此，甚至還有一個用於測試的舞台服務器黑匣子。 除了從那裡部署一個分支之外，我們什麼也做不了。 此外，我們無法像 .env 文件那樣配置我們的應用程序。 不允許進行此類操作的訪問。 您需要進行乞討，以便更改測試服務器上應用程序配置中的行。 （有一種理論認為，管理員感到自己對項目很重要，這一點至關重要，如果不要求他們更改配置中的行，那麼他們根本就不會被需要）。 嗯，一如既往，不是很方便嗎？ 這很快就會變得無聊，在與管理員直接對話後，我們發現開發人員生來就是為了編寫糟糕的代碼，他們本質上是無能的人，最好讓他們遠離生產。 但這裡也來自測試服務器，以防萬一。 衝突正在迅速升級。 與管理員沒有任何溝通。 由於他孤身一人，情況變得更加糟糕。 下面是一張典型的圖片。 發布。 某些功能不起作用。 我們花了很長時間才弄清楚發生了什麼，開發人員的各種想法都被投入到聊天中，但在這種情況下，管理員通常會認為開發人員應該受到指責。 然後他在聊天中寫道，等等，我糾正了。 當被要求留下一個故事並提供有關問題所在的信息時，我們得到了有毒的藉口。 不要把鼻子伸到不該伸的地方。 開發人員必須編寫代碼。 當項目中的許多身體動作都由一個人完成，而只有他才能執行每個人都需要的操作時，這種情況是極其悲傷的。 這樣的人，是一個可怕的瓶頸。 如果 DevOps 想法旨在縮短上市時間，那麼此類人就是 DevOps 想法最大的敵人。 不幸的是，帷幕即將關閉。
PS 在與人們聊天時談論了一些關於開發人員與管理員的問題後，我遇到了與我有同樣痛苦的人。 但也有人表示，沒有遇到過這樣的事情。 在一次 devops 會議上，我問 Anton Isanin（阿爾法銀行），他們如何以管理員的形式處理瓶頸問題，他說：“我們用按鈕取代了它們。” 順便一提 有他的參與。 我願意相信，好的管理員比敵人多得多。 是的，開頭的圖片是真實的對應。
資料來源：www.habr.com