SRE工程师-实习生
首先，让我自我介绍一下。 我 - ，组内前端工程师 GitLab。 上周，我有幸与我们的一位待命 SRE 工程师一起实习。 目的是观察值班人员如何应对日常事件并获得实际工作经验。 我们希望我们的工程师能够更好地了解用户的需求 监控::健康状况。
我得跟着SRE工程师到处走一周。 也就是说，我在交接时在场，监控相同的警报通道，并在事件发生时做出响应。
事故
一周内发生了 2 起事件。
1. 加密矿工
GitLab.com 周三的使用量猛增 'a，是由于试图利用跑步者的分钟数来挖掘加密货币而引起的。 该事件是使用我们自己的违规中和工具处理的，该工具会停止运行者的任务并删除与其关联的项目和帐户。
如果这个事件没有被注意到，自动化工具就会捕获它，但在这种情况下，SRE 工程师首先注意到了违规行为。 事件任务已创建，但其信息已关闭。
2. Canary 和主要应用的性能下降
该事件是由于 Gitlab.com 上的 Canary 和主要 Web 应用程序的速度变慢和错误频率增加引起的。 违反了多个 Apdex 值。
打开事件任务：
主要发现
以下是我在值班期间学到的一些事情。
1. 警报在检测到偏离正常情况时最有用。
警报可以分为几种类型：
- 基于特定阈值的警报，例如“每秒发生 10 个 5xx 错误”。
- 阈值是百分比值的警报，例如“给定时间请求总量的每 5% 出现 10xx 错误的频率”。
- 基于历史平均值的警报，例如“第 5 个百分点出现 90xx 错误”。
一般来说，类型 2 和类型 3 对于值班的 SRE 更有用，因为它们揭示了流程中与规范的偏差。
2. 许多警报从未升级为事件。
SR 工程师需要处理源源不断的警报，其中许多警报实际上并不重要。
那么为什么不将您的警报限制为仅真正重要的警报呢？ 然而，通过这种方法，您可能无法识别早期症状，这些症状将滚雪球般发展成可能造成重大损害的真正问题。
待命的 SRE 的工作是确定哪些警报实际上表明存在严重问题，以及是否需要升级和处理这些警报。 我怀疑这也是由于警报不灵活造成的：如果有多个级别或“智能”方式来根据上述情况配置警报，那就更好了。
功能建议：
3.我们的SRE值班使用了很多工具。
国内：
- GitLab 基础设施项目：这里有运行手册、轮班/周作业、事件响应任务。
- GitLab 问题：调查、审查和维护也在问题中进行跟踪。
- GitLab 标签：自动化任务使用特定标签启动，机器人使用这些标签来跟踪任务活动。
外观：
- PagerDuty：警报
- Slack：PagerDuty/AlertManager 消息流在此处。 与斜杠命令集成以执行各种任务，例如关闭警报或升级为事件。
- Grafana：关注长期趋势的指标可视化。
- Kibana：提供可视化/日志搜索，能够更深入地挖掘特定事件。
- Zoom：Zoom 中有一个持续运行的“分组讨论室”。 这使得 SRE 工程师能够快速讨论事件，而无需浪费宝贵的时间创建房间和链接参与者。
还有更多。
4.用GitLab监控GitLab.com是单点故障
如果 GitLab.com 遇到重大服务中断，我们不希望它影响我们解决问题的能力。 可以通过启动第二个 GitLab 实例来管理 GitLab.com 来停止它。 事实上，这已经对我们有用了： .
5. 需要考虑添加到 GitLab 的一些功能
- ，类似于 Google 文档。 这将有助于完成活动期间的事件任务以及汇报任务。 在这两种情况下，多个参与者可能需要实时添加一些内容。
- 更多用于任务的 Webhook。 从内部运行不同的 GitLab 工作流程步骤的能力将有助于减少您对 Slack 集成的依赖。 例如，能够通过 GitLab 问题中的斜线命令在 PagerDuty 中允许发出警报。
结论
SRE 工程师面临着很多复杂的困难。 很高兴看到更多 GitLab 产品解决这些问题。 我们已经在对产品进行一些补充，以使上述工作流程变得更加容易。 详情请参阅 .
我们将在 2020 年扩大团队规模，将所有这些出色的功能整合在一起。 如果有兴趣，请查看 ，如有任何疑问，请随时联系我们团队中的任何人。
来源： habr.com