在Slurm的评论中,Kubernetes表达了这样的短语:“ Kubernetes比我想象的要容易。” 现在不再听起来,k8复杂性的神话不再存在。 他进入易于学习,难以掌握的工具类别。
我们要对SRE重复相同的操作。 证明SRE比听起来容易和易于理解。 转变范例:让人们通过SRE工程师的眼光看项目。
和开始时一样,方程式中有许多未知数。 和一开始一样,最有趣的将放在第一位。

2月3-5日,我们将在莫斯科举办Slurm SRE。 三天的密集票费用为6万。 参与者将从中得到什么?
当我向朋友和同事介绍SRE时,我遇到了健康的怀疑:
- 我第一次听说SRE,这是一种炼金术。
- 对于像Google这样的巨头来说,实施SRE十分困难。
- 它既昂贵又长,他们不会给时间,他们不会分配预算。
- 您所描述的东西太好了,难以置信。
我想弄清楚这些问题。
现在是时候找出什么是SRE。
在口号级别:SRE是DevOps的实现之一。 它在十多年前出现在Google上,但直到最近才开始打入“常规”市场,这要归功于Google在2016年发行的《网站可靠性工程》一书。
该视频很好地描述了SRE和DevOps之间的连接:
不好的是,口号几乎没有。 好,DevOps,好,实施,下一个“好坏总有”。
您可以阅读这本书(这是值得的)。 但读者会发现自己处于一个从图纸研究空手道的人的位置。 这本书描述了这个概念,但并不适用于现实。 老师会沿着特定的路径引导手,指出过程中的错误。
价格包括对SRE方法和工具的快速而深入的审查。
实施SRE比听起来容易
在Slurma,我们将动手动动SRE:我们将选择指标,配置其度量,警报,遇到事件,解决和分析它们,根据所有SRE规范重建项目。
也就是说,我们将提供分步说明,您可以从密集课程归还后自行实施。
我在说谎 实际上,我们不会给出说明,而是一个示例,您可以从中得出许多想法和解决方案。
价格包括实施样本。
主要的问题是您必须说服那些没有去过Slurm的人。 因此,理想情况下,值得整个团队集中精力。 因此,我们为团体提供很大的折扣。
最好是由服务站领导来的Slerm。 CEO也很有用,关于此部分...
...如何说服最高管理者SRE是有用且必要的。
通常,CEO(高层管理人员),STO(IT管理人员),开发人员和运营之间存在任务冲突。
我不是故意说“利益冲突”,恰恰是任务冲突。
CEO需要财务业绩。 STO-一种可理解,可管理且尽可能舒适的情况。 也就是说,可以理解的任务具有可理解的业务价值,可以按时完成任务,具有正常的堆栈,更多的功能和更少的缺陷。 开发人员需要推出更多功能并加以利用-以确保可访问性(这显然与“更多功能”冲突)。
SRE说,该过程中的所有参与者都有一个任务:用户的幸福。 用户对新功能和服务可靠性之间的健康平衡感到满意。 快乐的用户支付更多的钱。 要管理用户满意度,您需要专门的工具。
此外,基于指标的SRE允许您将财务指标转化为各种指标的目标指标,进而将其转化为DevOps团队的任务。
允许您翻译-我夸大了。 这些指标的存在使您能够找到指标状态与财务指标之间的关系。 这是一项单独的大任务,但可以理解。
有一个DORA项目DevOps Research&Assessments ,它发布有关业务价值和ROI DevOps及其子类SRE的年度研究。 我们现在正在将当前报告翻译成俄文。 有一些评估公式可以一定程度地应用于您的公司。
简介:SRE通过设置指标目标为企业提供了管理财务绩效的机会,DevOps团队在查看当前指标值时清楚地了解了需要采取哪些措施才能最大程度地提高财务绩效。 哪位首席执行官会拒绝这种工具?
很有可能获得用于SRE实施的资源。
课程价格包括一组支持切换到SRE和DevOps的论点。
甚至在小型公司中,SRE也占有一席之地。
SRE分为工具,文化和组织结构。
大型和复杂项目需要一些工具,例如Service Mesh。 但是,可以在小型项目中实施相同的重试,退避,失败注入,正常降级,并且它们可以带来巨大的回报。
文化在任何公司中也很有用。 经典的管理员(设置Prometheus)将按照标准进行操作:它将包括内存和磁盘使用情况的监视以及其他熟悉的监视。 SRE工程师将首先与企业讨论业务流程的关键指标,然后进行监控。 显而易见,即使在微型创业公司中,SRE工程文化也很有用。
但是小公司的组织结构可能是不需要的,甚至是有害的。 如果所有员工都是通才,则无需强行分配SRE命令。
我们描述的一切都已经在起作用
该课程由长期在团队中实施SRE并长期生活在此范例中的人员创建。 Ivan Kruglov和Ben Tyler都是Booking.com的首席开发人员。 Google知名开发人员Eugene Varavva Tungsten Labs的CTO Eduard Medvedev是一名SRE工程师长大的。
Edward将于12月12日11:00举行网络研讨会“ SRE-HYIP还是未来?” 。
关于程序
至于程序。 我已经收到专家的反馈,说该程序没有奏效:它的范围太广,有时甚至不合逻辑。 真的是
实际上,我们为该程序提供了一个框架,并希望揭示一些想法。 在我们准备的过程中,我们还有两个月的艰苦工作,该程序将得到澄清:我们删除不必要的内容并指定剩余的内容。
但是,该程序已经以其当前形式清晰显示了我们的工作方向。
Slurm SRE程序主题1:SRE的基本原理和方法
- 成为SRE需要什么?
- DevOps和SRE
- 为什么开发人员欣赏SRE并在不在项目中时感到非常难过
- SLI,SLO和SLA
- 错误预算及其在SRE中的作用
主题编号2:分布式系统的设计
- 应用架构和功能
- 非抽象大型系统设计
- 可操作性/故障设计
- gRPC或REST
- 版本控制和向后兼容性
主题№3:如何接受SRE项目
- SRE的最佳做法
- 项目入学清单
- 记录,指标,跟踪
- 自己掌握CI / CD
主题№4:设计和发布分布式系统
- 逆向工程-系统如何工作?
- 我们协调SLI和SLO
- 能力规划实践
- 启动应用程序的流量,我们的用户开始“使用它”
- 发射Prometheus,Grafana,Elastic
主题5:监控,可观察性和警报
- 监控与 可观察性
- 使用Prometheus设置监视和警报
- 实际监视SLI和SLO
- 症状与 原因
- 黑匣子vs. 白盒监控
- 分布式应用程序和服务器可用性监视
- 4个金信号(异常检测)
主题№6:测试系统可靠性的实践
主题7:练习事件响应
- 压力管理算法
- 事件参与者之间的互动
- 验尸
- 知识共享
- 文化形成
- 故障监控
- 进行无责的汇报
主题8:负载管理实践
- 负载均衡
- 应用程序容错:重试,超时,故障注入,断路器
- DDoS(创建负载)+级联失败
主题9:事件响应
- 汇报
- 随叫随到
- 不同类型的故障(测试,配置更改,硬件故障)
- 事件管理协议
主题№10:诊断与解决问题
主题№11:测试系统的可靠性
主题№12:独立工作与回顾
以上所有都值得吗?
PS。 Kubernetes中心与它有什么关系
所有练习都是在Kubernetes上完成的。 拥有Kubernetes的人可以直接通往SRE工程师。 对于那些不拥有的人,请转到我们的Kubernetes课程 。