江苏龙网

  1. 首页 > 人文 > >

唯一机械 这14个问题不要错过，直播问答丨围绕故障管理谈SRE体系建设( 二 )


插件交流：https://twitter.com/gf_flowcharting
Q5：请问新组建的SRE团队应该怎样快速成长 ， 尽快成熟？从哪块入手比较好？
A：回归到IT管理的3要素上 ， 人员、流程、技术：
可以先从意识层面入手 ， 让大家的目标、思路能够基本保持一致；也就是人 。
然后约定一些必要的流程、规范、协助工具；约定统一的“语言体系”、沟通机制；在前面的基础上小步快跑 ， 逐步校正和迭代；这个事情不可能一蹴而就 ， 在实际工作需求中练兵；及时沟通、反馈 ， 多反思、复盘；这个点各更偏流程 。
技术的话 ， 作为一个基础点 ， 可以从先业务需求入手 ， 让团队把必备的技能拉齐到一个理想的水平线行 ， 先做到能hold住服务；在这个目标达成之后就可以考虑做更长远的技术规划和更深的技术探索了 。
Q6：现在SRE在美图发展的怎么样 ， 工具平台是否都能自己团队搞定？
A：还是看具体的需求场景 ， 注定有些需求是无法由单一团队完成的 ， 这时候就需要借助外力来辅助或共建 。
这里可以对齐一个理解和认知：全能全知的人是不存在的 ， 依靠团队的力量可以让一群人的能力得到互补和延展 ， 但同样也没有任何一个团队可以做到全能全知；这时候就需要有更高维的能力补充 ， 跨团队协作就是最常见的方式之一 。
所以 ， 我们需要明确好我们的目标是什么 ， 是解决具体的需求 ， 还是要打造一个全能的团队；怎么选择会更具可行性、ROI会更好 ， 这个或许就见仁见智了 。
Q7：对于Trace系统选型和实践 ， 美图是怎么做的呢？
A：基于开源的产品做了封装和适配 。 如果是小团队的话 ， 建议直接使用开源的产品 ， 目前这块的很多产品都是比较成熟的 。
Q8：请问服务降级、熔断通过什么技术手段可以实现？
A：一般可以从3个层次来做实现：
业务代码 。
业务框架 。
运维(基础)架构 。
个人感觉这个更多的还是要有相关的意识和理念 ， 在产品设计之初就考虑到这些点 ， 目前业界比较有名的技术应该是Hystrix 。
Q9：请问美图的SRE团队规模有多大 ， 是否还有专业组团队 ， 比如DBA团队 ， 基础架构团队？
A：SRE归属于运维部 ， 运维部内部是有职能划分的 ， DBA、大数据SRE、安全团队、基础SRE、产品SRE等；我目前负责产品SRE团队 ， 七八人左右 ， 还有HC ， 欢迎有意向的同学来聊 。 此外 ， 我们也有单独的基础架构团队 ， 跟运维部是兄弟部门 。
Q10：我们SRE太偏向业务 ， 缺少系统、或基础运维类 ， 后期会不会因为太稳定了 ， 自己干掉自己？
A：NoOps是会实现的 ， 但是SRE最终是基于什么样的原因被“干掉”可能会有很多种可能性 ， 我更倾向于相信是AI 。 但是没有必要因此而焦虑 ， 因为焦虑不能解决实际的问题 ， 我们能做到的就是警醒精进、奋力前行 ， 与君共勉 。
Q11：什么是SRE运维？从事SRE需要哪些技术知识点/SRE需要什么技术栈？SRE运维与DesOps运维有哪些差异？
A：这个问题可以参考Q1 ， 关于知识点和技术栈 ， 这个结合当下的大趋势 ， 建议大家从“云原生”的角度切入来打造自己的技术体系 。
Q12：美图不同的产品线 ， 都会定制特定的监控项目吗？
A：如果这里的“监控项目”指的是“监控系统” ， 是不会的 ， 我们有提供统一的、可以覆盖绝大多数场景的监控方案 。 如果确实有不满足需求的情况 ， 我们可以做一些个性化的适配然后做接入 ， 当然不同的业务是可以基于这些统一的监控方案来建设自己的“监控大盘”的 。
Q13：对于中间件这块的也是SRE在负责吗？
A：不一定 ， 不同的组件可能会由不同的团队维护 ， 有部分是SRE团队在负责的 。
Q14：像微服务的架构 ， 需要对每个服务都单独设定SLO吗？
A：理论上 ， 应该是这样的；因为不同的服务的核心程度是不一样的 ， 不同的服务的可用性目标也会有所差异 。


推荐阅读


上一篇：你的拍照男友|矮个子穿裙子要慎重，这3大雷区勿踩

下一篇：皮包公司|老总亲戚带项目上门签几十万大单子 原来是“皮包公司”