#運維俠客行·杭州站#關於業務、開發、架構、運維的思考

摘要： 4月23日運維俠客行·杭州站圓滿落幕，本次運維沙龍專門邀請了騫雲創始人、阿裏雲高級技術專家、優雲解決方案總監、袋鼠雲首席架構師為大家帶來了精彩絕倫的運維交流之旅。獻上第一疊開胃菜。

**運維俠客行特邀作者 **

黃河，平安壹錢包高級架構師，應用運維負責人。前支付寶、大眾點評資深運維工程師。

縱觀整個互聯網，整個技術部門，或多或少存在以下的情況：
開發（業務開發）：永遠被業務驅使或者強奸，越來越忙，支持業務越來越疲於奔命。產品、業務上線快，bug也很多。
** 架構：**一般中大型的互聯網公司，都會有架構部門或者小組。他們一般認為主要解決業務開發人員的需求，如提供RPC框架，消息中間件，緩存方案等，順便也顯示出其技術的水平就更好了。往往會出現，方案設計很漂亮，最終落地時卻問題百出。
** 運維：**絕大多數互聯網公司，運維的壓力主要在於支持日常的工作：環境搭建、產線配置、部署、SQL變更、數據庫擴容（垂直拆分）、網絡配置、防火牆配置、產線故障應急等。往往被日常支持工作綁架。
下麵的這組圖，就是現實：

相信以上圖組，大家看了都有很大的共鳴。這也是很多互聯網公司的現狀，BAT也不例外。
每個崗位怎樣跳出這樣的怪圈，竊以為：
業務開發：除了滿足產品提出的各種需求外，需要給留20%-40%的時間（用加班也行），想著怎樣優化本身的業務架構：如怎樣提升原來設計不合理的架構，優化之，提升穩定性、性能（容量）。一些通用的架構，需要提交到架構組，討論方案。個人認為，能滿足未來至少3年以上需求的架構方案，才熟合格。
** 架構：**除了解決一些業務開發的問題，設計架構，還需要重點考慮對運維的支持。一個架構產品最終成敗，產生的價值，既要滿足開發需求，也要滿足運維需求：穩定性、容量、可運維性要求。否則可能出現：上線後故障頻發，而且很難維護的局麵。
運維：除了滿足日常運維的工作（那是基本要求），需要參與到公司的整個架構規劃中去。結合PE、DB等角度，與業務開發、架構一起優化公司的架構設計。既能滿足公司發展的需求，也能很大程度上讓自己從日常雜務中解脫出來。
從根本上說：
業務給業務開發提出直接需求：要求產品設計成各種效果。
業務開發會給架構提出要求:我需要各個中間件滿足什麼樣的功能。
架構支持運維：各中間件的應該設計成怎樣，滿足開發需求。同時也要考慮提供怎樣的api，管理功能怎樣設計，才能提升可運維性和可擴展性，提升穩定性。
運維借助架構產品，自研產品，保障了產線的穩定性，也就支持了業務。
能達到這樣一種良性循環，就是我們技術人的長期奮鬥的目標：

覺得不錯，可以掃碼關注一下作者微信號哦