3）检验应急预案的有效性，如扩缩容预案，限流预案等
以压力测试为辅助，检验压力条件下，能否快速成功扩充容量，能否快速启动对业务限流。
4）提前发现服务稳定性隐患并推动消除隐患，建立故障快速发现和快速止损的能力
在某些特定的业务耗时增加、错误率增加时，能够快速启动预案介入，快速恢复业务成功率及耗时。
6 业务架构优化与业务柔性
优秀的架构需要具有自保护能力与对后端应用的保护能力。常见的保护能力如：某些高并发写请求入库前增加队列以增加瞬时吞吐能力。如高峰期扫场所码，扫场所码信息入库实时性要求并不强，采用腾讯云ckafka等组件进行业务削峰。在应用加入适当时长（如：5分钟）的缓存，用户短时间调用该数据时走缓存，以减少对后端、第三方接口的请求。该缓存可以加在前端（如Localstorage）或 后端（采用redis或hash到有状态服务的本地内存）。在后端或第三方接口故障时，由于用户会不断重试而瞬时增加大量请求，甚至导致后端雪崩，这时就有必要在前端增加限制重试的逻辑。比如有些小程序设计在用户请求出错后，会要求用户重登陆， 但如果对该登陆请求没有限制，必然会导致请求量过大而后台雪崩。我们建议在前端加上限频措施。以下是常见的前端设计：
后端在网关等层面限流，只允许承载能力内的请求进行后端。通过压测对系统承载能力摸底，从而在接入网关进行限流。我们采用腾讯云智能网关（腾讯云公有云API网关有同样的能力）限流。可以对后台起到相应的保护作用。第三方接口耗时太长，产生大量TCP连接而耗尽系统资源，此时会要求后端具有快速失败的能力，不再长时间等待第三方接口返回。
上图是健康码系统分层部署及各层对后端的保护能力。以上保护手段在每个项目中的实现策略均有所差异。因为涉及到用户体验，需要与业主充分讨论后执行。
7 变更控制
业务上线后，需要持续保持业务稳定运行，变更控制尤其重要，现网变更均需要提出变更请求，每一个变更请求需要进行技术严格评审后，经客户、管理授权后方能在现网实施。
我们特别使用腾讯云coding承载变更工作流，变更工作在平台中实现闭环。一个合格的变更请求至少要包含变更目的、实施过程、验证方案、回退方案等。ITIL 的 change management中均有规范，此处不再详述。变更时尽量遵循灰度发布，防止变更中产生较大影响面的问题。
以上是从技术架构、可观测体系、运营保障体系等运维体系各方面总结出来的、保障健康码过程中的心得，希望能给大家一些借鉴和参考。整体来说，技术架构上，基础资源尽量采用云原生产品，满足大容量、可伸缩、高可用的基础资源能力。可观测体系上，要采用云原生产品构建业务前端、后端一体化观测体系，保障业务可用性。运营保障体系上，好的系统运维是设计出来的， 一方面加强业务技术架构设计，可层可对后端提供保护，通过限流、逻辑熔断等手段使业务架构具有容错能力；另一方面平时要不断通过混沌工程演习手段，检验系统容量及高可用能力，保障团队能够及时响应，专业响应。
