今天，我们来简单聊聊关于SRE工程师的那些事
在正式开始之前，我先跟大家讲一下我的个人经历：今年春招找实习的时候，依稀记得那是一个日暖风和的中午，我坐在电脑前，而网线的另一端是和蔼可亲的面试官——是的，我正在进行一场某企业的技术面试，岗位则是SRE工程师
面试的前半段，我跟面试官相谈甚欢，不亦乐乎。直到面试官突然问了我这么一个问题：“你觉得运维工程师和SRE工程师有什么区别？或者说他们的工作性质有什么不一样的地方吗？”
这个问题直接把我问住了，运维工程师跟SRE工程师有什么区别？SRE工程师全名叫啥来着？顿时一个个问题涌上我的脑海，我只能尴尬的笑着并跟面试官说：“不好意思面试官，这个问题我没有过多的去了解”
面试结束后，果不其然的“挂掉了”
回到宿舍后，我对今天的面试过程做了一个总结复盘，我决心要弄清楚SRE工程师到底是什么，以及他跟运维工程师有什么区别，不然这都不懂的话我还应聘什么SRE工程师。
好，正文开始。
什么是SRE工程师？
SRE这个词诞生于谷歌公司，其全名叫网站可靠性工程师（Site Reliability Engineer ），它是软件工程师和系统管理员的结合。
在SRE诞生之前，谷歌认为“既然软件工程师职业主要专注于设计和构建软件系统，那么应该有另外一种职业来专注于整个软件系统的生命管理周期”。
SRE工程师都干些什么？
SRE工程师在最初的时候，主要的工作是负责维护谷歌网站的正常运转，所以我们看到SRE中的"S"最开始指代的就是谷歌的网站业务。
任何一个软件或者系统，我们认为其可靠性（Reliability）是相当重要的。因为绝大多数的大型软件或者系统，它们的生命周期绝大部分都处于“使用”阶段，而非“设计”或者“实现”阶段。一旦你这个软件或系统投入到生产环境并正式使用后，你就得想尽办法让它的用户体验更好，这样才能留住用户，给公司带来利润对吧。
所以说，SRE工程师的主要任务之一就是：负责软件和系统的架构设计，运维流程的不断优化，让这些大型软件以及系统运行得更加可靠，更加稳定，扩展性更好，更能有效地利用计算机资源。
世界上第一个SRE是谁？
在《SRE Google运维解密》一书中，作者跟我们谈到了SRE的起源——Margaret Hamilton，MIT教授。
他参与了阿波罗登月计划的软件开发工作，在阿波罗七号飞船研发的某天，MIT教授带着他的小女儿Lauren一起来到公司。小孩子嘛，对于新鲜事物都特别好奇，所以就在MIT教授忙着和组员们在计算机上进行飞行模拟测试的时候，他的女儿Lauren不小心按下了控制台上的DSKY键，这一按可不得了——整个模拟程序直接崩溃，导致火箭发射程序意外终止。
之后MIT教授发现，是因为当时Lauren意外触发了P01程序的执行，所以才导致了程序的崩溃（这个子程序是起飞前调试程序，执行时会删除现存的导航信息，如果在火箭飞行过程中执行这个程序，计算机将无法继续维持火箭航线，后果可是灾难性的）
MIT教授凭着自己的直觉，为项目组提交了一个软件改动，申请在飞行程序中增加一项特殊状态检查，以免飞行员在飞行过程中意外触发P01子程序的执行
但不幸的是，NASA管理层认为，这项错误发生的可能性太小，如果要修改的话成本太大，根本不值得。
无奈MIT教授只能在火箭飞行手册中写道：“请勿触发P01程序”
当时增加这段文字的时候，很多同事都觉得MIT教授在小题大做，因为他们都认为宇航员在经过如此长时间的专业训练，几乎不可能会发生这种错误
几天后，阿波罗8号飞船在执行一项任务时。宇航员Jim Lovell、William Anders和Frank Borman三人执行一个长达四天的飞行计划途中，Jim Lovell意外触发了P01程序，好巧不巧，当时正好是美国的圣诞节，大部分工程师都休假去了。
可想而知，当时NASA处于一片混乱状态，如此人命关天的时刻如果不能及时解决，三名宇航员恐怕就回不来了。
所幸当时MIT教授的飞行手册更新中恰恰提到了这种情形，并且提供了重新上传数据以及恢复执行的有效办法，在有效的时间内解决了问题，并拯救了宇航员的生命。
最后，我想说的是：没有人能够毫不出错地去做一件事，即使他是这个领域内最顶尖的人才。无论对一个软件系统运行原理掌握得多么彻底，也不能阻止人犯意外错误！
上文我们对SRE工程师有了一个基本的了解，别忘了还有一个问题：SRE工程师跟运维工程师有什么区别？
我们先看看某招聘网上企业分别对SRE工程师和运维工程师的技能要求，当然这只是一个大概的需求而且我只放了一张图片，具体还得看不同企业。大家可以自行去某招聘网站上了解。
SRE工程师
运维工程师
我们可以看到，两个职业在技能需求上其实没有太大的差别，都需要了解Linux操作系统，熟悉编程语言或者脚本语言。那么为什么还会有SRE工程师和运维工程师呢？以及他们直接有没有特别明显的区别呢？
区别？
传统的IT行业中，许多企业大多都是雇佣系统管理员来运维复杂的软件或者系统。
这些系统管理员的日常工作和研发工程师（软件工程师）相差甚远，通常属于两个部门：开发部（Dev）和运维部（Ops），这个团队模型也就是Dev/Ops分离模型。
于是，系统管理员也被称作运维工程师，他们主要负责将线程的软件组件部署在生产环境当中，并对外提供某种业务服务。
与运维工程师不同的是。SRE工程师不但负责传统运维工程师的工作，他们也负责软件工程师的一些工作——参与某些软件或系统的开发。
SRE团队相信通过开发软件系统来维护系统的正常运行，以此来代替传统运维工程师的人工操作，这样做大大节省了人力开销。
SRE团队中实现的是DevOps结合模型，他们主张用系统来维护系统，让SRE工程师有更多时间来负责软件系统的开发，而不是每天进行重复枯燥的运维工作。
最后，做个小总结：
- 随着IT行业的迅速发展，传统运维工程师已经不能满足企业的需求了，而SRE的诞生和DevOps理念刚好给企业提供了一个比较好的方案
- SRE更强调的是开发系统来运维系统，所以SRE的工作不仅要运维，还要对系统进行开发。这样做的好处就是避免了大量的人力消耗以及重复的人工运维操作
- 我们要重新造轮子，而不是重复造轮子
标签：面试官,运维,工程师,竟然,SRE,软件,MIT 来源： https://blog.csdn.net/s_alted/article/details/117535671
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。