SRE技术保障——艰难中启动（一）

公司主营业务是餐饮行业信息化，典型的TOB业务，围绕POS或收银机进行的积分、储值、点餐、支付、后厨打印等功能。

历经12年发展，目前线运行的核心业务，最老的核心代码还是11年老领导写的，最新的出自无锡第二研发中心的全新团队。

产品技术状况有2个特点

1、产品线长，技术栈多样，历史包袱重。

目前线运行的最老的产品线，部分核心代码是11年老领导写的，又经过5年多个团队的迭代、演进，此业务线上运行的Application数量，高达140+，底层依赖的数据库、缓存、消息、流计算、分布式计算、各路牛逼技术栈，维护工作苦不堪言。有些技术人员还对公有云技术心存芥蒂，来维护一下我们的这套系统，相信您会爱上公有云的各类商业化中间件。

2、客户使用场景对可靠性要求极高。

在餐厅前台待过，您就会知道哪怕1分钟不能下单或结账，收银员和顾客会对系统供应商报以何种的言语。传统3个9甚至4个9的可靠性衡量方式，在这种可靠性要求下没有任何用武之地，就像用体重计去称瓶装水是否足量。

产品稳定性必须作为未来的重点方向。

作为基础保障团队，虽然好大喜功的我，会有一种冲动两个问题全包圆。但理智告诉我，就这么几杆枪还是先搞定一项吧。

过去基础保障团队，只保障硬件、数据库、中间件这些基础架构层面。代码及应用架构问题，由研发团队负责。这样划分其实非常不合理：

几乎线上的所有产品技术事故，都不是一个团队能够独立负责的，粗暴的划分责任反而导致两个团队各自为政、甚至内耗。

比如汽车厂商的碰撞测试成绩，需要有一个专门的安全设计小组，来牵头协调车身设计、组装焊接各个部门协同改进，并最终对碰撞成绩的结果负责。

要想彻底改观公司新产品线的可靠性指标，也必须改变过去的行事方式，由一个独立团队，对可靠性指标负责。解决过去各自为政、推诿、可靠性结果无人承担的的状况。

全面的可靠性保障，在艰难中启动

参考业内的SRE（Site Available Engineer，网站可靠性工程师）的思想，结合目前技术团队状况。打算以运维团队为主导，协调少量架构、研发资源，一起尝试做一次变革。

我个人把这个项目当做一次内部创业。

愿景：打造一支专业的SRE团队，推动可靠性成为公司产品的核心竞争力之一。

18年的唯一目标：新产品线的事故数量，相较上个类似产品线下降80%。

1、没有任何新资源的情况下，硬挤出2个人，再从架构团队协调半个人，虽然艰难，但值得尝试。

2、目标是把事故数量下降80%，即便最终下降60%，也证明了这次变更的意义和价值，为未来指明方向。

---

罗重阳，18年6月3日，北京