关于业务、开发、架构、运维的思考

纵观整个互联网，整个技术部门，或多或少存在以下的情况：

开发（业务开发）：永远被业务驱使或者强奸，越来越忙，支持业务越来越疲于奔命。产品、业务上线快，bug也很多。

架构：一般中大型的互联网公司，都会有架构部门或者小组。他们一般认为主要解决业务开发人员的需求，如提供RPC框架，消息中间件，缓存方案等，顺便也显示出其技术的水平就更好了。往往会出现，方案设计很漂亮，最终落地时却问题百出。

运维：绝大多数互联网公司，运维的压力主要在于支持日常的工作：环境搭建、产线配置、部署、SQL变更、数据库扩容（垂直拆分）、网络配置、防火墙配置、产线故障应急等。往往被日常支持工作绑架。

下面的这组图，就是现实：

相信以上图组，大家看了都有很大的共鸣。这也是很多互联网公司的现状，BAT也不例外。

每个岗位怎样跳出这样的怪圈，窃以为：

业务开发：除了满足产品提出的各种需求外，需要给留20%-40%的时间（用加班也行），想着怎样优化本身的业务架构：如怎样提升原来设计不合理的架构，优化之，提升稳定性、性能（容量）。一些通用的架构，需要提交到架构组，讨论方案。个人认为，能满足未来至少3年以上需求的架构方案，才熟合格。

架构：除了解决一些业务开发的问题，设计架构，还需要重点考虑对运维的支持。一个架构产品最终成败，产生的价值，既要满足开发需求，也要满足运维需求：稳定性、容量、可运维性要求。否则可能出现：上线后故障频发，而且很难维护的局面。

运维：除了满足日常运维的工作（那是基本要求），需要参与到公司的整个架构规划中去。结合PE、DB等角度，与业务开发、架构一起优化公司的架构设计。既能满足公司发展的需求，也能很大程度上让自己从日常杂务中解脱出来。

从根本上说：

业务给业务开发提出直接需求：要求产品设计成各种效果。

业务开发会给架构提出要求:我需要各个中间件满足什么样的功能。

架构支持运维：各中间件的应该设计成怎样，满足开发需求。同时也要考虑提供怎样的api，管理功能怎样设计，才能提升可运维性和可扩展性，提升稳定性。

运维借助架构产品，自研产品，保障了产线的稳定性，也就支持了业务。

能达到这样一种良性循环，就是我们技术人的长期奋斗的目标：

原文来自微信公众号：运维求索

本文链接：https://www.yunweipai.com/12389.html