SRE技术保障——坚持前行（6/7月总结）

技术保障团队——践行SRE

SRE（Site Reliability Engineer），Google从创业之初就有这个职位并逐步沉淀出一套SRE理念，近两年国内互联网企业也纷纷引入。

SRE团队对云产品稳定性最终责任，运用全栈技术能力，从技术规范-监控体系-风险管理-自动化工具多角度入手，持续提升产品的稳定性及性能。

那么，雅座是否需要SRE？答案是肯定的

我们走过12年的历程，从最早的会员1.0->2.0->3.0，到雅座智能1.0->雅座收银2.0。产品越来越强大、并覆盖餐厅运营全周期的同时，餐厅对产品稳定性的要求也越来越高。最开始，故障影响的只是报表，后来故障影响客户会员积分交易，到现在，一个小小的故障都会影响客户点餐、后厨打印、外卖接单，直接导致餐厅彻底瘫痪。很难想象出哪家互联网企业，会比我们更需要SRE。

技术保障部成立

7月，运维团队被重新命名为【技术保障部】，这是对团队的重新定位，对未来团队价值的展望。

使命：

打造产品稳定性的强力保障体系，确保稳定性成为公司产品的核心竞争力之一。

职责：

1、运维及自动化；

2、建立稳定性/性能相关的技术保障体系：风险管理-技术规范-监控-自动化工具；

3、数据安全保障；

18年的目标：

1、初步建立公司层面的SRE保障体系，并切实有效，使收银2.0新产品线事故数比1.0下降80%。

2、运维自动化能力建设，运维及自动化团队控制在8人以下，高效管理5000台服务器、支撑5W家门店。

3、在无锡培养一支团队，能够独立承担运维自动化、SRE大部分工作。

6-7月我们的成果

技术规范

《需求评审规范1.0》、《代码报错及执行超时规范1.0》、《上线流程规范1.0》，不但规范成型，还跟进了监控、统计日报等技术手段，确保规范能够真正落地。

我们的职责是让这些规范在未来持续完善、补充和持续落地，相信能够成为技术团队的一笔宝贵财富。

风险管理

1、每周一次的风险梳理、排期、升级流程，持续运作。

2、重点推进解决了【大白鲨依赖小雅CRM】、【Api层授权补充】、【运维操作规范执行难】几个重点风险。

灰度环境2.0

1、业务团队可任选商户，10分钟内完成生产<->灰度的流量切换，用真实客户流量试点新版本代码。

2、高度仿真生产环境，共享一套网关、数据库、缓存、MQ、配置文件，并有效隔离。

3、从代码框架、代码规范、网关二次开发等多维度入手，全面支持收银2.0从点餐-下单-POS出单-支付-BOH的整个营业场景，涉及60多个应用程序，研发只需极少量代码改动。

4、原定8.17日上线，因业务要求提前到8.1，调集资源，客服各种技术难题/疑难BUG，如期上线并完成试点。

5、大部分工作由无锡团队承担，不论是代码框架编写、Nginx二次开发、外部资源协调。

运维平台

一键完成App迁移、简单扩容。

研发人员可自助完成缓存、MQ消息的查询。

配置中心正式上线，具备推广条件。

未来

下半年还有5个月，性能提升、代码规范推进、监控系统深入、灰度环境2.1、服务器集群管理、一键扩容等等，都给我们带来全新的挑战。

SRE团队的每一位伙伴，不论你过去擅长编码、数据库、网络、运维，需要我们一起加油！