SRE工程师-实习生
首先，让我自我介绍。 我是@ tristan.read ，是GitLab Monitor :: Health组的前端工程师。 上周，我很荣幸能与一位值班的SRE工程师一起实习。 目的是每天监控服务员对事件的反应，并获得真实的工作经验。 我们希望我们的工程师更好地了解Monitor :: Health 功能用户的需求。
我不得不跟随SRE工程师到处一周。 也就是说，我参加了值班，观看了相同的通知渠道，并对事件进行了回应（如果发生以及何时发生）。
突发事件
在一周内，发生了2起事件。
1.加密矿工
在星期三，GitLab.com看到了对GitLab Runner的使用激增，这是由于尝试使用跑步者分钟来挖掘加密货币而引起的。 我们使用自己的工具来消除事件，以消除违规行为，这将终止跑步者的任务并删除与之关联的项目和帐户。
如果未发现此事件，则将使用自动工具捕获该事件，但在这种情况下，SRE工程师将是第一个注意到此违规事件的工程师。 已创建事件任务，但是有关此信息的信息已关闭。
2. Canary和主要应用程序性能下降
该事件是由Gitlab.com上的canary和主要Web应用程序的速度下降和错误率增加触发的。 违反了几个Apdex值。
公开事件任务： https : //gitlab.com/gitlab-com/gl-infra/production/issues/1442
主要发现
这是我在值班一周中学到的几点。
1.当检测到异常时，警报最有用。
警报可以分为几种类型：
- 发生了基于特定阈值的警报，例如“每秒10 5xx错误”。
- 阈值是“给定时间每10％的请求总量中出现5xx错误的频率”类型的百分比值的警报。
- 基于“第90个百分位数中的5xx错误”类型的历史平均值发出警报。
一般而言，第二种和第三种类型对于值班SRE更有用，因为它们揭示了过程中与规范的偏差。
2.许多警报永远不会升级为事件
SR工程师正在处理持续不断的警报，其中许多警报并非真正重要。
那么，为什么不将警报限制为真正重要的警报呢？ 但是，通过这种方法，人们无法意识到雪球般演变成真正问题的早期症状，从而可能造成重大破坏。
SRE值班的职责是确定哪些警报确实说明了严重的问题，以及是否需要升级并开始理解它们。 我怀疑这也是由于警报的灵活性不足所致：如果根据上述情况引入了多个级别或“智能”的警报设置方法，将会更好。
功能建议： https : //gitlab.com/gitlab-org/gitlab/issues/42633
3.我们的SRE服务员使用许多工具。
内部：
- GitLab基础项目：运行手册在这里，每周轮班，事件响应任务。
- GitLab问题：在任务中也跟踪调查，分析和维护。
- GitLab标签：自动化任务是根据某些标签启动的，机器人通过它们来跟踪任务的活动。
外部：
- PagerDuty：警报
- 松弛：PagerDuty / AlertManager消息流在此处。 与斜杠命令集成以执行各种任务，例如关闭警报或升级为事件。
- Grafana：以长期趋势为重点的指标可视化。
- Kibana：在杂志中提供可视化/搜索功能，可以在某些事件中进行更深入的挖掘。
- Zoom：Zoom中有一个持续工作的“讨论室”。 这使SRE工程师可以快速讨论事件，而不会浪费宝贵的时间为参与者创建会议室和链接。
还有更多。
如果GitLab.com发生重大服务中断，我们不希望这影响我们解决问题的能力。 可以通过运行第二个GitLab实例来安装GitLab.com来停止它。 实际上，这已经对我们有效： https : //ops.gitlab.net/ 。
5.添加到GitLab时要考虑的一些功能
- 多用户任务编辑类似于Google文档。 这将有助于事件期间的事件任务以及解析任务。 在这两种情况下，几个参与者可能需要实时添加一些内容。
- 更多的网络任务。 从内部运行GitLab工作流程的各个步骤的能力将有助于减少对Slack集成的依赖。 例如，可以通过GitLab任务中的斜杠命令在PagerDuty中启用通知。
结论
SRE工程师在艰苦的日子中遇到许多困难。 很高兴看到更多的GitLab产品解决这些问题。 我们已经在努力增加一些产品，以促进上述工作流程。 有关详细信息，请参见《 Ops产品愿景》部分 。
在2020年，我们将扩大团队以整合所有这些出色功能。 如果有兴趣，请阅读职位空缺 ，如有任何疑问，请随时与我们的团队联系。