时常会写写博客，于是想干SRE这么多年，是否可以成体系的将从业经验总结一下，形成一个在大厂SRE场景下的实践手册，内容涵盖大型互联网系统的稳定性保障、DevOps自动化、逃生能力架构设计、技术运营、SRE成长等主题，坚持挑战写到现在，乐高式的拼在一起，终成体系。文章皆是工作中的实践总结，每个场景问题的解决、方法论的提炼，均来自自己一线的工作和管理实践。通过这本实践手册，希望帮助想进入SRE这个行业
故障是无法避免的，所以作为一个大型互联网系统，逃生能力的架构设计尤其重要，一个具备优秀逃生能力的系统，在故障发生后，可以把用户影响降到最低甚至无损，多年在小爱/米家一次次大小故障的处理和复盘中，慢慢形成了一些经验和方法的思考。大型互联网系统，模块多、依赖关系和运行环境复杂，逃生能力一定是要拿出来当做独立主题来思考设计的，目标是打造一个架构皮实的高可用系统，而不是一个脆皮，一碰就崩。为了阐述清楚如何
作为一名大厂SRE，对什么是好产品（技术架构角度）有深刻的感悟。一个好产品的技术架构不仅在优秀的代码本身，更体现在后期的易运维性、可扩展性、高可用性上。随着用户体量、产品功能、IaaS、PaaS的变化甚至员工的离职，随时需要动态调整架构改变策略来应对各种问题，而这些场景都是对技术架构是否优秀、是否有张力的一次次考验。如果是新产品，在早期SRE就要参与进来了，同步参与制定接入架构、部署架构、高可用架
由于证书的时效限制，因证书过期忘记更换出现的故障屡见不鲜，而且影响都比较严重，用户量越大，灾难性越强。既然大家都知道证书的破坏力，那么为什么过期问题还是接二连三的出现呢？分析看，一来证书是一个正常时期少有人关注的东西，只有过期了才知道他的破坏力，容易忽视轻敌；二来在互联网企业，随着业务线的增长，证书可能成百上千，再加上最初的使用没有做好规划，在这个背景下，叠加业务调整、人员流动，证书一多管理上的漏
随着行业的发展，运维职能在发生微妙的变化，现在谈大厂SRE的方向，其实我觉得更像是技术运营，通过运营的方式技术的手段牵头协同各部门来保证产品的SLA（服务质量），控制产品的成本，提高管理的效率，从传统运维转身至SRE，SRE慢慢从后台部门走向前台，从成本部门走向生产力部门，从系统稳定性走向用户稳定性，未来甚至会参与到前端经营，SRE是有数据技术能力的。作为技术运营来说，最重要的是拿到产品运行的各种
自动化体系在一个技术团队中尤其重要，他代表着效率和未来。在运维团队，我认为SRE自动化的终极目标就是建立一套DevOps体系，能够把所有的运维场景承载下来并全部自动化，全链路的提升SRE的工作效率、解放人力，为此在团队里我提出了自动化的北极星：能自动化的全部自动化。解放人力不是把自己干掉，我认为自动化的本质是改变了运维团队的工作结构，比如原来需要铺在一线人肉处理的事情改为自动化，鼓励SRE多用工具
科学的制定流程制度是非常重要的，好的流程制度能提高生产效率、降低出错，但流程制度用不好是要阻碍创新的，甚至引起工程师的反感和抵触。比如为了减少工程师出错，把工作的每个角落铺满精细的流程制度规范，每个制度事无巨细的几千上万字，无异于对工程师缚手缚脚，大家也背不过来，唯一的用途就是犯了错误追责任：看，有流程制度你不遵守。事无巨细的流程制度，是反人类、反人性的，谁能记得住呢？长期积累下去，组织的能力、效
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
