手机端做的优秀的网站设计,无货源一件代发平台,北京微信公众号定制开发,上海十佳装修公司排名参考来源#xff1a; 极客时间专栏#xff1a;赵成的运维体系管理课 极客时间专栏#xff1a;全栈工程师修炼指南 赵成大佬在鹏讯云社区的文章#xff08;77篇#xff09; 有了CMDB#xff0c;为什么还要应用配置管理 故障没有根因#xff0c;别再找了 如何理解CMDB的套…参考来源 极客时间专栏赵成的运维体系管理课 极客时间专栏全栈工程师修炼指南 赵成大佬在鹏讯云社区的文章77篇 有了CMDB为什么还要应用配置管理 故障没有根因别再找了 如何理解CMDB的套路 故障复盘的简洁框架-黄金三问 数据中心运维管理方案超详细–数据中心场景的运维工作场景 https://www.uwintech.cn/2 --EasyOps一站式运维平台关于运维专业化公司(优维科技)的介绍 关于 SRE 这个角色你可以参看 Google 自己的描述以及 SRE 这个词条
运维的组织架构
从实际的人员管理以及技能维度来划分的话互联网公司的运维团队差别不大基本会分为如下几个岗位 基础运维包括 IDC 运维、硬件运维、系统运维以及网络运维 应用运维主要是业务和基础服务层面的稳定性保障和容量规划等工作 数据运维包括数据库、缓存以及大数据的运维 运维开发主要是提供效率和稳定性层面的工具开发。
这个实体的组织架构相当于是从技能层面的垂直划分。 基础运维更擅长硬件和操作系统层面的运维 应用运维可能更擅长业务稳定性保障、疑难问题攻关以及技术运营等 数据运维就不用多说了DBA 本身就是专业性极高的一个岗位 运维开发则是支持上述几个岗位日常运维需求的是否能将人力投入转换成工具平台支持就看这个团队的能力。
SRE岗位
书籍《SREGoogle 运维解密》 SRE 关注的目标不是 Operation运维而是 Engineering工程是一个“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位。我们从 SRE 这本书的前面几个章节可以看到谷歌不断强调 SRE 的工程能力。
书中对 SRE 的职责定义比较明确负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。如果站在价值呈现的角度我觉得可以用两个词来总结就是“效率”和“稳定”。
SRE 的能力模型不仅仅是技术上的还有产品设计、标准规范制定、事后复盘总结归纳这些技术运营能力同时还需要良好的沟通协作能力这个就属于职场软技能。
SRE直译过来是网站稳定性工程师。表面看是做稳定的但是我觉得更好的一种理解方式是以稳定性为目标围绕着稳定这个核心负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。
分解一下这里主要有“管理”和“技术”两方面的事情要做。
管理体系上涉及服务质量指标SLI、SLA、SLO、发布规则、变更规则、应急响应机制、On-Call、事后复盘机制等一系列配套的管理规范和标准制定等。 技术体系上以支持和实现上述标准和规范为目标涉及自动化、发布、监控、问题定位、容量定位最终以电子流程串联各个环节做到事件的闭环。
– SRESite Reliability Engineer网站可靠性工程师这个角色最早很可能是 Google创造出来的从名称上也可以看出这个职位的工程师所致力于解决的问题就是网站可靠性的问题这里的“可靠性”包括可用性、延迟、容量等多个方面。
在“时间就是金钱”的压力环境下严谨而大胆快速定位和解决问题但更重要的是帮助不同的团队“防患于未然”比如主导和把关新建服务的可靠性设计。SRE 有时要解决基础设施的问题有时要分析服务端的压力来源有时则要搞定网页上造成大量用户访问困难的“小 bug”。很显然一个狭窄领域知识的工程师是不可能胜任这样的岗位的对于从端到端俯瞰整个流程的能力Web 全栈工程师有着天然的优势。
CRE 岗位
CRECustomer Reliability Engineering直译过来就是客户稳定性工程师。
CRE 出现的根本目的就是消除客户焦虑真正地站在客户的角度去解决问题同时对客户进行安抚、陪伴和关怀。
通常的售后支持都是你问什么问题我就回答什么问题能马上解决的就马上解决不能解决的就转到后端处理然后让客户等着承诺多长时间内给出答复。这种流程标准严格执行 SLA 规范对于一般问题还好但要是真的出现大问题就不行了。
CRE 这个角色一定是站在客户角度解决问题。加入客户的“作战室”War Room和客户一起排查问题不解决自己不撤退还会随时通报进展必要的时候会将故障升级到更高的级别寻求更专业的资源投入以共同解决同时根据客户的不同反应进 行不同方式的安抚。
CRE 还会发挥谷歌多年积累下来的非常宝贵的线上运维经验在日常就跟客户沟通传递一些稳定性保障的知识。 CRE 可以按照谷歌总结出来的类似 SRE 的标准规范对客户线上系统进行稳定性标准评审并给出专业的建议。如果客户同意遵守这样的标准规范执行在后续出现故障时CRE 就完全可以按照非常成熟的 SRE 的运作模式去协作用户处理故障这样就会大大提升 CRE 和客户的协作效率为故障快速处理赢得更多宝贵时间。同时 CRE 也可以发挥更大的专业作用而不是之前的对客户系统不熟悉空有一身绝世武功却使不上劲。
服务心态
总结了一下是不是有服务心态表现在我们的做事方式上就是我们是否能够站在对方的角度考虑问题、解决问题。
1. 多使用业务术语少使用技术术语
与合作部门沟通协作特别是对于非技术类的业务部门尽量多使用业务语言来表达。在讨论一个需求时如果表达的都是 API、缓存、数据库、消息队列等等这些专业术语估计业务部门的同学肯定是跟不上我们的思路的这样的沟通通常无法正常地进行下去所以就会 经常出现业务同学说业务的事情技术同学说技术的事情两边不能达成一致矛盾就产生了。
技术是实现业务功能的一种手段和方式所以一定是从业务角度出发考虑技术解决方案而不是从技术角度出发让业务来适配技术。
尝试用业务语言去沟通用对方能够听得懂的表达方式去表达你的技术观点。为了让业务人员理解你的想法就自然会用业务的思路去思考和解决问题了。这个需要一点点改变可以先从尝试开始。
2. 学会挖掘问题背后的真正诉求
外部提出的一个问题可能并不一定是真正的问题而是问题的一个解决方案。 遇到类似问题可以不着急动手做先多问自己和对方几个问题比如 为什么要这样做 谁要求做这件事情的 这样做的目的是什么 这样做是为了解决什么问题
这一点其实也是站在对方角度去考虑去思考对方要解决的问题是什么而不是解决我们的问题。通常情况下两三个问题后一般就会暴露出背后最原始的那个需求了。正所谓“磨刀不误砍柴工”问题和背景搞清楚了思路和方案就是顺其自然的事情了。
3. 解决问题的时候关注目标而不是聚焦困难
两种不同的思考问题的方式带给人的感受也是完全不一样的。 随着云计算技术的深入发展公有云事业也不断拓展运维领域的分工也在不断地精分细化而每个细分领域对专业技术的要求也越来越高专业的服务化程度也越来越高。我想这是一个好现象让原来非常模糊的运维行业范畴变得越来越清晰、越来越具体。 一方面我们要不断提升自己的技术能力另一方面也要注意自身服务意识的培养让自己的能力得以发挥创造更大的价值获得更好的回报。 所以CRE 这个角色既具备良好的专业技术能力又有非常强的问题解决能力同时还要具有优秀的客户沟通和关怀能力。
运维职业发展方向
1.一线维护
这个团队是负责产品的交付服务和后续的客户服务工作。从技能上很像传统运维主要是对网络设备、硬件主机和操作系统层面要熟练。一方面要负责交付的项目管理另一方面也是非常重要的一点要对一线客户满意度负责也就是客户反馈的所有问题甚至是客户工作中表现出来的喜怒哀乐都要关注。
一线维护最重要的就是必须要有非常强的服务意识。
2.二线技术支持
因为一线维护面对的是单个具体的运营商在遇到一些问题的时候往往没有经验但是二线因为要面对某个产品全球的局点问题所以在经验上更容易沉淀和积累。当某个一线团队遇到没有经验的问题时二线有可能就可以很快很好地帮忙解决而不用直接透传到三线。 同时二线还要做好统筹协调因为一线过来的问题不仅仅是产品本身问题也可能是网络设备、硬件、操作系统、存储甚至数据库等的问题这就需要二线帮助一线协调专家资源进行处理而不是一线再一个个找人这时一线只管反馈问题即可。
二线技术支持大多由产品研发或者一线维护经验的人员抽调上来的即使没有这些经验也要下放到一线去锻炼很长时间两三年都有可能所以技术和经验上都相对更加全面同时能够有较强的推进协调能力。
3.三线研发维优
到了三线就是研发团队中的运维团队了这个团队在华为叫做维优团队。这个团队就很牛了一般都是从开发骨干精挑细选出来的一方面是为了锻炼人另一方面也是为了在出现问题时能够有最专业、能力最强的人响应处理因为电信级业务是国计民生的基础设施 一般传递到三线的问题都是比较严重或者疑难的了必须投入精兵强将第一时间解决问题。
处理问题的过程中还会不断完善工具体系提升日常维护和问题定位的效率。因为三线同样要面对全球局点问题所以 7*24 响应而且常年无休比我们现在互联网运维的工作负荷要大得多所以这个团队成员一般做个 1~2 年就会转岗晋升不然身体肯定是承受不住的。
三线研发维优这个团队的成员就像军队中的突击队或尖刀连一样总是冲在最前面在高压状态下解决最复杂、最棘手的问题所以从选拔阶段就有非常高的要求。最终经过这个团队磨练出来的人技术能力、沟通协作能力以及全面解决问题的能力都是非常突出的。自然地在晋升发展方面就会有更大竞争优势。
这里我们不做过多发散理解下来就是谁离客户最近谁对客户负责谁就能代表客户谁就有最大的话语权甚至是指挥权和决策权。体现在上述我们所说的运维机制上就是一线的声音代表了客户声音一线反馈到二线的问题二线必须响应二线传递到三线的问 题三线必须响应。
客户第一
当然问题级别不同响应效率可以不同。同时三线可以根据客户现场情况以及问题严重程度对问题进行升级以知会到更高层级的主管进行关注。
在考核上如果一线提交的问题最终被定性为二线支持问题或者三线研发质量问题那二、三线的全年考核将会受到影响如果是频繁出现问题那就会受到严重影响而且各级主管要承担连带责任。
这套机制的根本目的还是为了促进整个体系能够以尽快解决问题、提升软件质量为目标。整个团队树立起这样的观念就自然会对质量和问题有敬畏感研发维优那个时候大多都是远程电话与一、二线沟通潜意识里就会把一、二线作为他们的客户同样保持谦卑和尊重。
从价值呈现的角度看运维岗位
运维能力的体现,一定是整体技术架构能力的体现。所以要想做好运维就一定要跳出运维这个框框从全局的角度来看 运维要考虑如何打造和体现出整个技术架构的运维能力而不是运维的运维能力。这一点是根本一定要注意。如果我们仍然片面地从运维的角度看运维片面地从运维的角度规划运维是无法走出运维低价值的困局的。
当我改变了这个认知后我的出发点就回归到了效率、稳定和成本这三个对于研发团队来说最重要的目标上来。从运维的角度来说能够与这三个点契合的事情我总结了以下五个。
1. 运维基础平台体系建设
这块主要包括我们前面提到的标准化体系以及 CMDB、应用配置管理、DNS 域名管理、资源管理等偏向运维自身体系的建设。这一部分是运维的基础和核心我们前面讲到的标准化以及应用体系建设都属于这个范畴。
2. 分布式中间件的服务化建设
在整个技术架构体系中分布式中间件基础服务这一块起到了支撑作用。这一部分的标准化和服务化非常关键特别是基于开源产品的二次开发或自研的中间件产品更需要有对应的标准化和服务化建设。这也是我们无意识地割裂运维与技术架构行为的最典型部分这里容 易出现的问题我们前面讲过你可以回去再复习一下。
3. 持续交付体系建设
持续交付体系是拉通运维和业务开发的关键纽带是提升整个研发团队效率的关键部分。这个部分是整个软件或应用的生命周期的管理体系包括从应用创建、研发阶段的持续集成上线阶段的持续部署发布再到线上运行阶段的各类资源服务扩容缩容等。开发和运维的矛 盾往往比较容易在这个过程中爆发出来但是这个体系建设依赖上面两部分的基础所以要整体去看。
4. 稳定性体系建设
软件系统线上的稳定性保障包括如何快速发现线上问题、如何快速定位问题、如何快速从故障中恢复业务、如何有效评估系统容量等等。这里面还会有一些运作机制的建设比如如何对故障应急响应、如何对故障进行有效管理、如何对故障复盘、如何加强日常演练等等。同样这个环节的事情也要依赖前两个基础体系的建设。
5. 技术运营体系建设
技术运营体系也是偏运作机制方面的建设最主要的事情就是确保我们制定的标准、指标、规则和流程能够有效落地。这里面有些可以通过技术平台来实现有些就需要管理流程有些还需要执行人的沟通协作这些软技能。
最终通过这样一个规划我把团队以虚拟形式重新规划了不同职责分别负责基础平台体系、分布式中间件服务化体系、持续交付体系和稳定性体系基本就是上述的前四件事情。
对于最后一个技术运营体系这一点作为共性要求提出。我要求团队每个成员都要具备技术运营意识。 具体来说就是要能够有制定输出标准的意识和能力 能够有规范流程制定的能力同时能够将标准和流程固化到工具平台中最后能够确保承载了标准和规范的平台落地也就是平台必须可用确实能给运维团队或开发团队带来效率和稳定性方面的提升。这些对个人的要求还是比较高的要有一定的规划、设计和落地能力能具备一整套能力的人还是少数目前这块还是靠团队协作来执行。
