应用运维日常工作记录

导读

本文记录了作者在负责XJ品质业务运维的日常工作。针对应用运维的系统性价值思考,有专门的文章作介绍,因此本文并未进行深度抽象。

组织分工

围绕着一个业务线,通常会有产品、运营、研发、测试、运维、中间件、安全、效能等多个组织分工协作。如下图,

page.png

其中,

  • 研发主导业务,对上对接产品和运营,向下实现各项业务功能
  • 运维支持业务,一般对生产环境稳定性负责,需要得到运维工具、安全工具、质量工具、中间件工具等众多工具的支持
  • 测试支持业务,对测试质量负责
  • 中间件支撑业务,一般分为基础中间件(如mysql redis mq等)和业务中间件(如支付中台、分单中台等)
  • 安全、效能等部门也会对业务起到支持作用

业务运维为了达成自身目标,一般需要协调调度各方资源和能力。如,SRE与QA合作共建代码质量管理、变更质检等,SRE与SEC合作实现风控策略。当然,SRE最主要的沟通对象还是业务研发童鞋。业务研发是资源的集中调度方,但因线上环境的重要性,业务研发天然的和SRE合作的机会更多。

工作内容

业务运维主要工作可以分为业务支持、稳定性建设、效率提升、成本优化、性能优化五类,每一类的功能内容见如下列表。

page.png

对于国内大部分业务为王的互联网公司来说,业务运维工作的建设优先级可以总结为:稳定第一、效率第二、成本第三、其它最后。

一些思考

  • 服务者心态:运维是用来支持业务的,天然需要处理好和业务方的主从定位,跪舔并不可耻
  • 成事的态度:业务周边有很多支持类角色,SRE可以抱着补位者的心态,做好运维兜底工作
  • 实事求是的精神:公司规模、业务、用户习惯等有差异,经验需要结合实际情况
  • 套路和创新:进过20多年的发展,业务运维很多工作已经有成熟套路。如何将套路合理落地、何如超越套路,值得思考
  • 业务运维的宿命:所有组织分工的初衷,都是为了充分利用人力资源、培养专业竞争力。统一的业务运维组织、和业务团队的分离,本质上是在运维专业性和业务人效上找了一个折中,很难得出完全的对错。


Prev     Next