先说下我这哥们吧！
今年35岁，是我大学室友，性格真是属于那种典型老好人，不争不抢上学那会没见他跟谁红过脸，这些年一直在北京一家互联网公司做运维工作。因为在大学时期我俩关系就比较好，所以也一直没有断联系，昨天晚上给我发微信说跟公司新来没多久的90后上司干了一架......
说实话，当时挂完电话我这心里五味杂陈的，不知道是该心疼我这哥们替他抱不平，还是.....今天想了很久要不要把他这件事分享出来，后来又联系了他，他本人倒是挺看得开的。
给大家说下事情的经过吧，我这哥们上个月部门空降一负责人是个90后，有没有背景啥的咱就不知道了，在公司做事挺雷厉风行的，不过人家技术确实没的说的，上面的领导也都很认可他，我哥们他们部门人不算多，他算的上是待的时间最久的一个，平时跟同事也都和和气气的做着自己的本职工作。
昨天他们部门开会，这个90后说要新招一批人，扩团组建SRE团队（说实话没有问度娘之前我也不太了解这是个什么）后来还含沙射影的说现在组内成员水平怎么怎么样，整一个阴阳怪调的，当时一个同事听不下去回怼了两句就出去了，他这经理估计觉得脸上没面当时就火了，矛头就指向了我哥们“能力不行就是不行，还不让说，你们看看杜永（我哥们）整天看他忙来忙去忙了个啥，就这水平真不知道留在公司有什么用”
我哥们听到这也急了，俩人就在办公室争执起来大吵了一架，然后就是大家前面看到的.....我哥们和他另一个同事被劝退了！
挺心疼我这哥们的，虽然大家常说“此处不留爷自有留爷处”但毕竟不是20多岁的年轻小伙，老子不爽了我就不干，像我这哥们35岁突然失业，车贷房贷压身，家里还有上小学的孩子，现在要从新开始找工作....说实话挺难的，其实反过来想想，是不是我哥们真的能力不行，已经跟不上公司的节奏了，淘汰是必然，只是提前了而已？
事后我给我另一个朋友冠宇打了个电话，他之前在美团做架构师，现在单独出来创业了，就想着看看他们公司要不要人，也想着帮下我这哥们。
后来我俩也聊到了我哥们他们经理说的SRE这个岗位。冠宇给我发一个SRE技能图谱，让我转发给我哥们，让他参考看下有那些地方需要提升。我也仔细看了下，觉得这份图谱挺实用的，这里分享给大家希望也能对你们有些帮助。
这份图谱涉及的知识点太多了，可能会看不太清楚，紫色标记的是需要大家以后重点要掌握的技能，大家可以看下，我这边之前还收藏了一份IT行业技能知识图谱，里面包含了架构师、java、云计算图谱等等，都是很实用的，也分享给大家。
（架构师技能图谱）
上面这些只是截取了一部分，想要原版高清图可以加下我助理回复“SRE技能图谱”“IT技能图谱 ”她这边可以打包一起分享给大家
（扫码领取完整版高清原图）
和冠宇聊完后我去网上查询了关于SRE的相关资料，感觉挺受益的，现在很多一线大厂的企业包括腾讯、阿里、字节跳动、百度甚至一些中小型公司都在扩展组建SRE团队，有些公司甚至不要求学历和经验，只要技术够硬薪资开到30k以上都不是问题。
下面是我整理的一些关于SRE的相关知识仅供大家参考！
为什么诞生 SRE？
原因一：企业成本的增长同用户的增长不成线性变化。但是随着系统的复杂度提升，组建越来越多，用户的流量压力也越来越大，相关的变更也会越来越多，各模块之间的变更顺序也会越来越复杂。在这样的情况下，单纯的靠运维人力的数量提升无法满足业务的发展需求，而且会提升企业的成本；
原因二：传统的研发团队和运维团队天然具有冲突。公司的IT人员的配置：研发（Dev）和运维（Ops），研发部门聚焦在快速构建和快速发布；运维部门关注的是如何避免发生故障，从目标上讲就是矛盾的。且随着 IT 技术的发展，对 IT 从业者的要求也越来越高，既要懂得底层系统，也要懂得数据算法，同时对主流技术还要快速追赶，满足这样要求的人才太少；
原因三：生产工具为适配生产力发展的必然产物。为了提高IT行业的整体效率和质量，使得从手工运维时代，逐渐过度到脚本工具运维，在发展到平台数据运维，再到平台软件运维，在发展到智能自动化运维。通过一系列手段、工具、理念的进步，将 Ops 技术发展到 DevOps、DataOps、AIOps 等；
关于SRE的几个认知误区
1、SRE 就是运维
SRE不止于运维，确实部分公司的SRE岗位工作内容与传统的运维或者系统工程师相近，但主流或者说未来的SRE是一个技能综合性岗位，不仅需要运维能力，也需要软件工程能力、技术架构能力、编码能力、以及项目管理与团队协作能力。
2、SRE 不需要懂业务
脱离了业务的架构是没有灵魂的！不懂业务的SRE是不合格的SRE，SRE要参与的技术与运维架构的优化与未来规划，同时也要协同业务团队完成故障排查，疑难杂症的处理，这些工作没有对业务的理解是无法很好的完成的（甚至无法完成）。
SRE工作模式就是以增加网络稳定性、减轻网络运维工作量为目标，运维工程师自主开发以实现自身的IT自动化和智能化需求，在不增加人力成本的同时有效减少个人运维工作量。这也是未来SRE工程师取代传统运维工程师的关键所在。
SRE与DevOps
“DevOps” 这个术语在 2008 年末出现，其核心原则：IT 部门在系统设计和开发的每个阶段的参与、严重依赖自动化与人力投入、工程实践和工具在操作任务中的应用，与许多 SRE 的原则和实践一致。
人们可以将 DevOps 视为几种核心 SRE原则向更广泛的组织，管理结构和人员的推广。可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。
目前国内很多一线大厂互联网企业为了提升用户价值的交付效率，都在积极采用微服务、容器等分布式技术和产品，也在积极引入像 DevOps 这样的先进理念。
这些公司，选择了正确的架构演进方向和交付理念，效率自然提升了一大截。但你会发现，效率提升的同时，挑战也跟着来了：引入如此众多的先进技术和理念后，这种复杂架构的系统稳定性很难得到保障，怎么办？
答案就是：SRE。
SRE 到底有什么过人之处呢？给大家分享下SRE稳定性保障规划图：
所以说，近几年业界对 SRE 的关注越来越多，大家几乎达成了共识——Google SRE 就是目前稳定性领域的最佳实践。甚至可以说，SRE 成为了稳定性的代名词。
上面这些也是我整理的一些关于SRE的皮毛知识，想更加深入了解这个岗位的，不妨看下我朋友冠宇对SRE大厂工程师成长路线的一个详细描述，纯干货分享很值得一看！
年薪50w云计算架构师及SRE大厂工程师成长路线图
↓↓↓
如果大家想要视频里的文档的话，也可以添加我助理，SRE技能图谱、架构师图谱等都可打包发给大家！
最后说点啥呢？只希望我这哥们能赶紧重新调整好状态投入一份新的工作中去吧，同时也算是给大家提个醒，社会时代在进步当别人脚步越来越快时，如果我们不去抓紧时间提升自己的技能，终究也是要被这个时代给淘汰！前路漫漫，上下求索吧！
560
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
