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

为扩大运维派影响力,网站及其公众号转让中,有意微信:helloywp

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

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

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

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

下面的这组图,就是现实:

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

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

每个岗位怎样跳出这样的怪圈,窃以为:

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

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

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

从根本上说:

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

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

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

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

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

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

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

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2019 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部