SRE和系统运维的最大区别，我认为SRE得在系统运维的基础上研究业务，研究系统架构、产品架构，SRE面向的是用户稳定性。大型互联网系统，模块多、依赖关系和运行环境复杂，如果不了解系统架构，在出现问题时基本就是抓瞎的，不知道服务的功能，不知道到故障后对用户的影响，不知道出了问题后查哪些指标，不知道服务依赖了哪些第三方资源，不知道服务间是怎么调度的，等等都会让SRE局限在系统外的狭窄空间，只能被动的接
大型互联网系统的服务和指标都是海量的，对应的告警也特别多，即使做了很多的分级和收敛，往往很多小问题依然会触发一堆P0，反应不出产品的真实影响。因为是P0，所以大家都是绷紧神经处理，可能只是几个边缘服务异常抖动，并不影响网民用户，但循环往复，弄的大家很疲惫，长此以往，大家对P0也就不那么敏感了，和狼来了的游戏一样，质量的隐患也就这么埋下了。举例几年前我刚接手小爱、米家的运维时，发现工程师基本是通过告
故障处理troubleshooting是做互联网SRE最心跳的事情，没有之一，也是考验一个SRE是否能够独挡一面的最有效方式。首先它的发生是随机的，完全未知，尤其是大型互联网系统，海量的用户，故障发生后精神高度紧张，要顶着巨大的压力，用最短的时间协同各方制定方案、恢复业务，尤其考验一个人的综合素质。其次，处理期间要面临各种老板、质量部门和未知部门未知人员的盘问，各种客服报过来的用户投诉和催促（PS
关于SRE和运维体系的文章很多，但大多数学院风浓厚，本文试着从一个出身运维一线SRE管理者的角度进行总结阐述，给你一份可实操接地气的运维体系，所有感悟来自在面向大型、复杂互联网系统的治理时，尤其离不开SRE，当体量上来后，系统的用户量、模块、调用链、指标、主机、域名、4/7层、日志等等都会到一个巨大的级别，甚至还要继续增长，如何保证运维架构的合理、资源和服务管理的有序，如何经营好这些资源，用最低的
故障处理trouble shooting是每个SRE要做的日常，特别是处在快速成长期的大型互联网系统，模块多、变更多、访问量大、用户环境复杂，不就是这坏就是那坏，SRE就像一个医师，需要在故障时协同研发动各种手术去修复系统，常用的修复的方法一般会提前梳理准备好，我们称作预案。经过无数次的故障处理，发觉是有一些不变的套路的，每次故障处理基本都是围绕这几个套路在做排列组合，其中最常用的6个，我把他总结
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
