之前负责的浏览器业务，业务运维主要工作是质量成本和效率

架构梳理

面向用户视角，梳理出整个系统的架构，包括服务模块，数据模块以及第三方调用，明确核心模块和数据，提高响应的管理，比如针对变更、故障设置更高的优先级、还有有响应的容灾和降级方案（我们之前一般分为3级，一级为核心模块，二级为普通模块，三级为内部模块），此外，这些模块的核心SLO也要放到大盘关注。例如我们当时的信息流模块是核心模块，他是调用第三方字节的信息流推荐，所以我们针对字节的接口做了拨测告警，日常的变更也会拉通会议沟通，明确新功能的影响范围，是否在核心功能路径上，以及相应的单元测试和回滚测试。

监控梳理：

主要从系统监控，服务监控和数据监控等几个部分。一般针对系统监控公司内部的监控都会包含，服务监控我们当时主要基于核心接口构建的SLO错误预算体系。根据错误消耗来决定我们系统的一个状态。同时也会根据日志监控，统计关键字来确保系统的稳定，当时为了定位更快速，调用链能力不可或缺。此外，我们也会根据故障排查过程中发现的指标，加入监控配置。当然这一块我们还是比较克制，尽量保证指标的唯一性。当时配置了网卡的dropped，overruns指标，，这两个指标可以发现网卡的配置错误，SYNs to Listen dropped应用的性能或者配置错误

变更管理

变更前沟通变更模块的优先级，然后确认变更的范围，是否在核心业务的关键路径，是的话需要重点关注保障。其次，明确研发已经进行了单元和回归测试，以及回滚方案，特别是针对携带变更表字段的服务变更，需求明确说明相关数据库是否需要回滚以及回滚的方案。最后，开始发布，我们一般是先在预发布环境，完整的测试功能后。再灰度发布应用，首先是灰度内部用户，然后逐步扩大范围，直到同步到全网。同时，我们要关注相应的监控指标，看是否有异常，如有异常，按照回滚方案及时回滚。

容量水位

资源这块，目前k8s提供了deployment HPA的能力，我们需要设置好应用的上限和下限数量，保障服务可以在正常的水位运行（目前我们一般认为CPU水位在70%为正常水位），日常也要巡检系统，当发现资源水位超限后，我们要及时定位原因，明确是用量增加导致的，调高资源水位。不是用量增加的，我们需要定位相关的原因，（之前遇见过一个很有意思的服务，一开始用C 语言写的，后面用c++重构，发现CPU整体的使用量升高50%多，导致资源不足，后面也是经过多轮定位，结合perf，火焰图等，发现是编译的时候没有启用优化参数，导致代码的性能比较低）。其次我们也要关注带宽指标，包括服务接口带宽和CDN带宽，确保维持在正常的水位

容灾方案和降级方案

核心和普通模块要确保容灾保障，比如多机房或者异地部署，我们当前的系统是多机房部署，在北京的昌平和大兴。当时经常有机房光纤被挖断，所以体会特别深，没有容灾机房，那就是服务无法服务。其次，核心模块要有降级方案，当时我们的浏览器就是会保留一些信息流到redis存储，再调用第三方接口异常的时候，我们可以在降低时效性的情况下，依然可以提供服务，保障了用户的使用
故障演练： 定期组织故障演练，目前腾讯有混沌系统，专门用来模拟系统的一些异常情况，比如服务器关机，主机资源异常，断网以及自定义命令输入等，验证系统是否监控触达、高扩展和高可用，以及一些其他的问题

全链路压测

全链路压测可以有效的发现系统的平静点，针对提升系统的整体吞吐非常有效。
准备工作：录制线上的流量，代码也要相应改造，可以识别请求头的标识，数据写入到影子表以及设置过期时间的redis信息，同时mock一些相关第三方接口。防止影响线上数据。明确观察的监控指标。
开始压测： 录制的流量打标，并向系统发起请求，前期流量小一点，后续逐渐增加，同时观察指标的情况，当发现指标异常的情况，分析调用链，查看异常点。
压测分析：分析异常点的原因，然后改造，后续可以继续发起全链路压测