Close

CheckOps

CheckOps 活动是每周一次的实践活动,旨在指导 DevOps 团队审查运营指标、跟踪重要事件并制定可操作的目标。随着时间的推移,CheckOps 活动可以改善开发人员体验,组建更健康的团队,从而开发出更出色的软件。

铅笔图标
准备时间
30 分钟
跑表图标
执行时间
45 分钟
相互连接的人的图标
人数
3-10
人们握手的拼图

CheckOps

CheckOps 活动是每周一次的实践活动,旨在指导 DevOps 团队审查运营指标和重要事件并制定可操作的目标。随着时间的推移,CheckOps 活动可以改善开发人员体验,组建更健康的团队,从而开发出更出色的软件。

人们握手的拼图
铅笔
准备时间
30 分钟
跑表图标
执行时间
45 分钟
相互连接的人的图标
人数
3-10

CheckOps

CheckOps 活动是每周一次的实践活动,旨在指导 DevOps 团队审查运营指标和重要事件并制定可操作的目标。随着时间的推移,CheckOps 活动可以改善开发人员体验,组建更健康的团队,从而开发出更出色的软件。

铅笔图标
准备时间
30 分钟
跑表图标
执行时间
45 分钟
相互连接的人的图标
人数
3-10
人们握手的拼图

CheckOps 运用实例

Teams can run CheckOps directly in Compass. Compass offers teams a single place where they can easily see metrics and goals and write down actions they plan to take.

一份每周 CheckOps 报告样例,其中包含指标、警报和计划的措施。

您也可以在 Trello 中运行每周 CheckOps 报告。

您需要什么

远程

具有屏幕共享功能的视频会议

数字协作工具

面对面

Compass 中的 CheckOps 报告模板

白板

记号笔

便利贴

计时器

可选模板

Atlassian 模板

本活动最适合搭配 Compass 中的 CheckOps 功能(请参见如何让您的团队开始着手 CheckOps)。如果您尚未开始使用 Compass,当前仍然可以在 Trello 中开始跟踪团队的运转情况。

运行本剧本的说明

本活动专为开发、交付和运行软件的团队而设计。

1. 准备实践活动 30 分钟

设定您的 DevOps 团队目标

The entire team will set goals together.

  • 登录 Compass 并导航到 CheckOps 功能,或者准备一种跟踪目标的替代方法。
  • 确定开发或运营实践中您想要变更或改进的方面。

业务需求可以指导您的运营目标:

  • 您是否需要为客户提供尽可能快的服务,或者您是否需要全天候提供服务?针对延迟、吞吐量或可用性设定 DevOps 目标。

运营目标也可以来自团队:

  • 您的团队是否厌倦了在夜晚不知什么时候就会被无力解决的警报和事件惊醒?设定目标,最大限度地减少事件和不可操作的警报的数量。
  • 您是否发现等待审核拉取请求的时间太长了?设定一个运营目标,确定您的拉取请求保持待解决状态的时间长度。

从少量 DevOps 目标开始。保持简单,确保收集正确的信息来跟踪进度。如果可以,请从所有服务中设定一个或多个相同目标开始,这样可以更轻松地将重点放在每次会议都会审查的数据上。

确保 DevOps 目标可衡量

以可衡量的方式定义目标,以便可以明确地知道自己是否实现了目标。

  • 通过服务的运营指标可以做到这一点:使用可观测性工具(例如 Splunk Observability、DataDog、Grafana 等)并明确描述想要影响的指标。
  • 存储库的开发指标也很重要—您可以使用 Jira SoftwareCompass 更好地跟踪这些指标。

当您完成这项练习时,可能会发现您没有衡量实际要改进的方面。没关系!第一次 CheckOps 会议的操作项之一可能是添加相关的 DevOps 指标。完成后,您可以在以后的会议上再予以公布。

写下 DevOps 目标

一旦团队接受了您设定的目标,就把它们写下来并与所有人分享—这些即是您宣布的运营目标。然后,设置一个易于访问且清晰的 Confluence 基础文档,并在其中存储您的 DevOps 目标。如果您使用的是 Compass,则可以在记分卡中设定目标。

您的 DevOps 目标可以(也应该)随着时间的推移而变化。当您收集了更多信息时,您将能够就目标做出更明智的决策,或者您可能会发现您的业务或运营目标在发生变化。但是,请注意,不要一次添加太多的目标和 DevOps 指标,因为这样最终可能会削弱团队的注意力,而无法实现预期的结果。我们建议在三到六个月内最多设定三个目标。

您的团队可能选择的一些目标示例包括:

  • 增加拉取请求或总周期时间 (TCT):如果您的团队经常错过截止时间,则很有用。
  • 减少团队每周应对的警报或事件的数量:如果您团队的工作经常受到干扰,则很有用。
  • 降低部署频率:如果您的团队收到的事件过多,则很有用。

随着您的团队变得更健康,您可能会发现准备阶段会变得更短。

提示:主要 DevOps 指标

我们建议团队始终衡量以下指标

  1. 变更的提前期
  2. 变更失败率
  3. 部署频率
  4. 平均恢复时间

2. 收集数据 15 分钟

After the team sets goals, the presenter will need to gather data. Keep in mind, though you may not need to run step one every week, you will need to gather data each week.

做好记录

从一次 CheckOps 会议到下一次会议,会发生您的工具无法捕获的重要事件。考虑到人类记忆的易错性,值得把这些细节都写下来,以便您可以在下次会议中解决。

如果您是远程团队成员,请每周创建一份新的 CheckOps 报告,在报告中可以添加重要事件,然后将其分享给相应的团队成员。如果您使用的是 Atlassian 的开发人员体验平台 Compass,则可以从运营状况详细信息页面快速轻松地启动 CheckOps 实践。

  • 待命人员被寻呼后发现警报是误报?这肯定会影响您团队的开发人员体验,因此请注意这一点,并与群组进行分享,以便您以后做出改进。
  • 是否发生过事件,部署事件失败或合并拉取请求花费太长时间的情况?在一周内快速做好笔记,这样团队以后就不必根据记忆来修复事件了。

做好审查准备

As the on-call rotation ends (or right afterwards), the presenter should prepare the CheckOps report for that rotation. At its simplest, the report should include:

  1. 您要为其运行 CheckOps 的服务/组件的列表。
  2. 针对每个组件的目标的衡量标准。
  3. 使用对勾(打勾)或叉号(打叉)来指明目标是否已实现。
  4. A mitigation plan for any unmet goals, as well as notes from the presenter about why the goal wasn't met.
  5. 用于记录后续操作的部分。
  6. 任何其他事件或异常情况的摘要。

在 CheckOps 报告中记录后续行动至关重要。否则,当您想要的是推动改进的反馈回路时,得到的只会是一份状态报告。

3. 召开 CheckOps 审查会议 30 分钟

每个人都在发挥作用

Keep it interactive! Everyone on your DevOps team who takes a turn being on-call should attend this meeting, and everyone should have a job:

  • 主讲人:刚刚结束待命轮换的人员应展示 CheckOps 报告及其发现。如果您在团队中没有待命职责,可以指派一个人来记下本周发生的事件,并可以在此活动中展示其发现。
  • 下一次待命:此人应密切关注演示者的观察结果,包括他们看到的事务或可能在下一次待命轮换中再次出现的风险领域。
  • Leader: The leader is the person (or people) who can help the team prioritize actions and ensure followup. When an action requiring follow up arises, the leader should help make sure the right person (or people) owns the action and will be able to see it through to resolution.
  • Other on-call team members and component owners: These are the people who are also in the on-call rotation and/or are intimately familiar with the services or components that are being operated.

分享和讨论发现

演示者将向团队介绍每个服务/组件,并将分享是否实现了目标以及相关原因。他们将讨论给定服务发生的所有运营事件或异常情况,并分享他们的观察结果和分析。团队负责提出问题并帮助提供后续行动建议。

共同努力,设法确保 DevOps 团队的所有服务/组件都能实现各自的目标,这是整个团队的工作。

写下每个团队成员将要采取的行动,并在会议期间在待办事项列表中创建工作单。

提示:积极行动,而非被动回应

当您的团队负责实现运营目标或开发目标时,很容易陷入被动回应的误区。无论是可靠性、交付速度还是代码质量,CheckOps 推动的数据驱动方法都应使您的团队能够实现 DevOps 目标,增强开发人员体验并持续改进。


跟进

迭代

我们建议每周开展 CheckOps Play,并使其与团队的待命值班表交接保持一致。第二步和第三步每周都会重复,但您可能不需要每周都执行第一步。在您随着时间的推移不断练习 Play 的过程中,第一步和第二步所需的时间将会缩短。您的团队开展 CheckOps Play 几周后,可能就有机会扩展和发展您的实践,将其他重点领域包括在内。例如,您可以衡量质量指标(如代码覆盖率)、业务指标(如给定功能的每周活跃用户数),或者任何其他有助于改善团队运行状况的指标。

重新评估您的运营目标

Over time, the original DevOps goals you set may no longer meet your team's needs. Maybe the business needs changed, or the targets became more or less aggressive. If so, run step one, update your stated operational objectives, and continue your practice. You can also expand the scope of your CheckOps practice, if necessary, to cover more services or components or other aspects of your operations practice.

自动报告

随着范围扩大,您会发现您需要将更多时间花在分析上,而减少在报告工作上花费的时间。设法自动收集关键指标并生成 CheckOps 报告。随着越来越多的报告工作实现自动化,这将提高团队工作效率和开发人员体验。

如果您增加了自动化功能,请确保仍会花时间分析收集的数据,为 CheckOps 会议做好准备。Atlassian 员工使用 Compass 中的指标来帮助满足这方面的需求,我们也在产品内集成了 CheckOps 体验来帮助您实现这方面的目标。

运营目标示例

反思

以下是一些运营目标示例,您的团队可以根据职责来构建 CheckOps 实践:

Delivery types

Possible objectives

Microservice

  • - Latency

  • - Availability

  • - Error rate

On-call team

  • - Actionable alerts and incidents

  • - Proactive vs. reactive time spent

Software delivery

  • - Pull request cycle time

  • - Deployment frequency

  • - Code coverage

  • - Support ticket count

Mobile application

  • - Error rate

  • - Adoption


人群插图

还有问题?

与其他 Atlassian 使用手册用户开始对话、获取支持或提供反馈。

人群插图

还有问题?

与其他 Atlassian 使用手册用户开始对话、获取支持或提供反馈。

相关战略

注册时事通讯插图
注册时事通讯插图

从我们的团队到您的团队

通过我们的每月时事通讯了解最新的剧本、提示和窍门。

Thanks!