This post is Private. Only a writer or those who know its URL can access this post.

SRE Workbook Ch.17 過負荷の特定と回復(Identifying and Recovering from Overload)

SRE チームが円滑に運営されているとき、チームメンバーは自分たちの仕事のすべてを快適に処理できているかのように感じるでしょう。
彼らはチケットに取り組むことができるでしょうし、その上で、将来的のサービスの管理をより簡単にするよう長期を見据えたプロジェクトに取り組む時間があるはずです。

しかし、時には状況がチームの作業目標を妨げることもあります。チームメンバーは長期の病気で休みを取ったり、新しいチームに移動したりします。組織は SRE の新しいプロダクトと言える規模のプログラムを引き渡してきたりします。サービスまたはより大きなシステムへの変更は新しい技術的挑戦をもたらします。
作業負荷が増加するにつれて、チームメンバーはチケットとページを処理するために多くの時間を費やすようになり、エンジニアリングに時間を使えなくなります。懸命に働いているのに進歩を感じられないことで、チーム全体として、ストレスやフラストレーションを感じ始めます。その結果、ストレスによって人々はミスをしがちになり、信頼性、そして、エンドユーザーへの悪影響に繋がります。つまり、チームは日々の業務を制御したり、効果的にサービスを管理したりすることができなくなります。

この時点で、チームはこの過負荷状態から抜け出す方法を見つける必要があります。チームメンバーが重要なエンジニアリング作業に集中できるように、作業負荷のバランスを取り直す必要があります。

原文

By Maria-Hendrike Peetz, Luis Quesada Torres, and Marilia Melo with Diane Bates

When an SRE team is running smoothly, team members should feel like they can comfortably handle all of their work. They should be able to work on tickets and still have time to work on long-term projects that make it easier to manage the service in the future.

But sometimes circumstances get in the way of a team’s work goals. Team members take time off for long-term illnesses or move to new teams. Organizations hand down new production-wide programs for SRE. Changes to the service or the larger system introduce new technical challenges. As workload increases, team members start working longer hours to handle tickets and pages and spend less time on engineering work. The whole team starts to feel stressed and frustrated as they work harder but don’t feel like they are making progress. Stress, in turn, causes people to make more mistakes, impacting reliability and, ultimately, end users. In short, the team loses its ability to regulate its daily work and effectively manage the service.

At this point, the team needs to find a way out of this overloaded state. They need to rebalance their workload so that team members can focus on essential engineering work.

運用負荷 (または運用上作業負荷 )は、システムおよびサービスを最適なパフォーマンスで実行し続けるための継続的なメンテナンスタスクを表す用語です。3 つの異なる種類の運用負荷があります。 ページ 、 チケット 、および 継続的な運用上の責任 です。ページは通常、即時対応を必要とします。緊急の問題に関連するチケットは厳しい締め切りがあることでしょう。ページも緊急のチケットも、SRE がチームの運用責任をサポートするエンジニアリングプロジェクトに取り組むのを妨げます。そのため、それらを割り込みと呼びます。
SRE 本の 第 29 章 では、チームが複雑なシステムを動かしているときに自然発生する割り込みを管理するための手法について説明しています。

原文

Operational load (or operational workload) is a term that describes the ongoing maintenance tasks that keep systems and services running at optimal performance. There are three distinct types of operational load: pagestickets, and ongoing operational responsibilities. Pages typically require immediate attention, and tickets related to urgent problems can have tight deadlines. Both pages and urgent tickets interrupt SREs from working on engineering projects that support the team’s operational responsibilities. For that reason, we refer to them as interruptsChapter 29 of *Site Reliability Engineering* discusses techniques to manage the interrupts that naturally arise when a team is maintaining a complex system in a functional state.

SRE本29章のまとめ(抜粋)

- メンバーが出来るだけ 認知的フロー状態 で作業できるようにするべき
- 割り込み対応をしながらプロジェクトの作業・コーディングをすると、フロー状態に入りにくい
- 割り込み対応をする時間と、プロジェクトの作業をする時間はしっかり分けるべき
- 業務時間全体を割り込みに集中しているときには、割り込みが割り込みではなくなる
- コンテキストスイッチのない期間が、1 週間に及べば理想的
- 1 日、あるいは半日の方が実際的かもしれない
- エンジニアが毎日仕事に来る際には、自分がプロジェクトの作 業だけを行うのか、割り込み対応だけを行うのかが自分で分かっているようにすることが重要
- プライマリオンコールエンジニアは、オンコールの作業だけに集中すべき
- 1 人のエンジニアに対し、オンコールを担当しながら同時にプロジェクト(あるいはコンテキストスイッチのコストが高いその他の何か)を進めることを 求めるべきではない
- セカンダリオンコールエンジニアも、責務によっては割り込み対応に集中すべき
  - セカンダリではない誰かがチケットの処理に割り当てられているなら、その役割をセカンダリにまとめてしまうことを検討した方が良い
- ページの量が多い場合にセカンダリが実際にプライマリを手伝うことが期待されているなら、セカンダリもまた 割り込み仕事を受け持っておくべき
- 割り込み対応をする役割は、分散しているべきではない
- 後始末の作業(色々と綺麗にしたり整頓したりする作業)がなくなることはない
- 更新しないといけないドキュメント
- 綺麗にないといけない設定
- 小まめな「後始末の作業」は未来のオンコールエンジニアの役に立つし、将来の割り込みを減らす
- チケットをランダムに割り当てる運用はやめよう!
- チケットの負荷も分散させるべきではない
- 可能な限り、チームの誰でも職責を引き受けられるような役割を規定すべき
- そうしないと割り込みを誰かに集中させることが難しくなる
- チケットはその場しのぎで対応するだけでなく、根本原因まで潰されるようにするべき
- チケットの引き継ぎ手順をプロセスを定義すべき
- チケットやページは、チームとして定期的に洗い直すべき
- 顧客と共に自分も尊重しましょう
- 時には顧客に押し返しても良い問題もある。

運用負荷をチームが管理できなくなった時、チームは 運用過負荷 ( 作業過負荷 とも呼ばれる)の状態になります。緊急の問題が継続的にプロジェクト作業を邪魔するため、チームが重要な優先事項に向かって前進できない、そんな状態のことを運用過負荷状態と言います。過負荷はチームの優先すべきものや、サービスの向上を妨げるだけでなく、エンジニアがエラーを犯す可能性を高めます。[1](http://landing.google.com/sre/workbook/chapters/overload/#ch17fn1

原文

When operational load outstrips a team’s ability to manage it, the team ends up in a state of operational overload (also called work overload). A team is in a state of operational overload when it can’t make progress toward key priorities because urgent issues continually preempt project work. In addition to detracting from the team’s priorities and service improvements, overload can increase the chance that engineers make errors.1

運用過負荷のしきい値はチームによって異なります。Google の SRE チームは、エンジニアの時間の 50%で運用作業を制限しています。SRE チームを成功させるには、長期にわたって、彼らが管理するサービスの運用負荷を軽減するために必要なエンジニアリングプロジェクトを完了できるという自信が必要です。

原文

The threshold of operational overload can vary from team to team. Google SRE teams cap operational work at 50% of an engineer’s time. A successful SRE team must have confidence that over the long term, they will be able to complete the engineering projects required to reduce the operational load for the services they manage.

この章では、運用過負荷が発生している困難な状況から適切に管理された作業負荷に、Google のチームがどうやって改善したかについて説明します。2 つのケーススタディは、運用過負荷がチームの健康にもたらす有害な影響、およびチームが長期的に影響力のあるプロジェクトに集中できるようにするために日常業務に変更を加えた方法を示しています。
ケーススタディ 1 では、縮小していくチームの残りのメンバーが作業負荷に追いついかず、過負荷が発生しています。
ケーススタディ 2 では、チームは知覚された過負荷に苦しんでいます。これは実際の作業負荷の誤認から始まりますが、運用過負荷と同様の悪影響があります。

原文

This chapter describes how teams at Google progressed from a difficult situation characterized by operational overload to a well-managed workload. Two case studies show the detrimental effect of operational overload on team health, and how the teams made changes to their daily tasks so they could focus on long-term impactful projects. In Case Study 1, overload results when remaining members on a shrinking team are unable to keep up with the workload. In Case Study 2, a team suffers from perceived overload—a state that has the same effects as operational overload, but starts as a misperception of the real workload.

これらのケーススタディでは、2 つの Google SRE チームにおいて有効だった具体的な取り組みを取り上げていますが、過負荷を軽減するための戦略」のセクションでは、あらゆる企業または組織に適用される過負荷を識別および軽減する方法について説明します。この章は、過負荷に陥っているチームの管理者、または過負荷を心配している SRE チームに役立つでしょう。

原文

While these case studies highlight specific actions that worked for two Google SRE teams, the section Strategies for Mitigating Overload provides practices for identifying and mitigating overload that apply to any company or organization. Therefore, this chapter should be useful to managers of overloaded teams, or any SRE team concerned about overload.

負荷から過負荷になるまで(From Load to Overload)

その発生源に関係なく、過負荷は生産性を損なう可能性がある職業的ストレスです。
放置すると深刻な病気を引き起こす可能性があります 。SRE チームにとって、運用負荷は通常、認知負荷の高いタスク(メモリリークやセグメンテーションフォルトのデバッグなど)と頻繁なコンテキストスイッチを発生させる小さなタスク(クォータ要求の処理、ロールアウトの開始など)の組み合わせです。

原文

Regardless of its origin, overload is an occupational stress that can cripple productivity. Left unchecked, it can cause serious illness. For SRE teams, operational load is typically a combination of cognitively difficult tasks (like debugging memory leaks or segmentation faults) and many small tasks that require frequent context switches (working through quota requests, starting binary rollouts, etc.).

チームがこれらすべてのタスクを処理するのに十分な時間がない場合、作業の過負荷が頻繁に発生します--チームに割り当てられたタスクが期限内に完了できない場合は、客観的に明らかです。知覚された過負荷はより主観的であり、チームの個人が仕事が多すぎると感じたときに発生します。これは通常、組織や仕事上の変更が短期間でいくつか発生したときに起こりますが、その変更についてチームと指導者がコミュニケーションを行う機会はほとんどありません。

原文

Work overload often happens when a team doesn’t have enough time to handle all these tasks -- an objective reality when the number of tasks assigned to a team can’t be completed within the given deadline for each task. Perceived overload is more subjective, and happens when individuals on the team feel that they have too much work. This usually happens when several organizational or work changes take place over a short period of time, but the team has little opportunity to communicate with leadership about the changes.

オンコール中にどのような問題が発生するのか、または作業負荷がどうなるのかが明確になることはありません。ディスクスペースの不足に関する一見して無害な一つのチケットが、定期的なガベージコレクションジョブの徹底的な調査につながる可能性がある一方で、20 以上のページのについて、悪い監視であることが判明するかもしれません。
作業負荷の見積もりや予測が難しい状況においては、認知バイアスの影響を受けやすく、作業負荷を誤判断する可能性が高くなります。。たとえば、チケットキューがオンコール中に終わらせるには大きすぎると判断できない場合があります。もしすべてのチケットを素早く終えることができて、そして実際の作業負荷が低いとしても、最初にチケットキューを見た時、過負荷を感じるものです。
この知覚された過負荷[2](http://landing.google.com/sre/workbook/chapters/overload/#ch17fn2)はそれ自体が、仕事に対するアプローチや態度に影響を与える心理的要素を持っています。「仕事が多すぎるという先入観を持って一日を始める」ということがなければ、チケットキューを自分のやり方で処理していきやすくなります。
たぶん一日中仕事をしても、チケットキューを消化できないでしょう(つまり仕事の過負荷に直面している状況にある)。しかし過負荷を感じながら一日を始めた時よりも、ずっと多くの進捗を出せるでしょう。

原文

It’s never clear what problems will develop when you’re on-call, or what your workload will be. On the one hand, a single, seemingly innocent ticket about running out of disk space might lead to an in-depth investigation of a recurring garbage collection job. On the other hand, a pager storm with 20+ pages might turn out to be a case of bad monitoring. When it’s hard to estimate or predict your workload, you can easily fall victim to cognitive biases and misjudge your workload—for example, you might gauge a ticket queue as too large to finish during your on-call shift. Even if you can finish all the tickets quickly and the actual workload is low, you *feel overloaded when you first look at the ticket queue. This perceived overload2itself has a psychological component that affects your approach and attitude toward your work. If you *don’t* start your day with the preconception that there’s too much work, you’re more likely to dive in and start working your way through the ticket queue. Perhaps you work all day and don’t finish your workload (thus facing work overload), but you make a lot more progress than if you had started your day feeling overwhelmed.

多くの割り込みが累積すると、作業の過負荷につながる可能性がありますが、必ずしもそうなるとは限りません。
しかし、頻繁な中断が外部のストレス要因と対になっていると、大きな作業負荷(または小さな作業負荷でさえ)が容易に認知された過負荷に変わる可能性があります。このストレスは、他のチームメンバーの失望、仕事の不安、仕事上または個人的な葛藤、病気、または睡眠不足や運動不足などの健康上の問題から生じる恐れがあります。

原文

Accumulating many interrupts can lead to work overload, but it doesn’t have to. But when frequent interruptions are paired with external stress factors, a large workload (or even a small workload) can easily turn into perceived overload. This stress might stem from the fear of disappointing other team members, job insecurity, work-related or personal conflicts, illness, or health-related issues like the lack of sleep or exercise.

仕事が適切に優先順位付けされていない場合、すべてのタスクが等しく緊急のように見えるものです。そして、実際の負荷と認識される負荷の両方につながります。実際に過負荷が発生した場合、チケットやアラートの緊急であれば、たとえ長時間労働が慢性化している状況かも、問題が解決するまでチームメンバーが作業することになります。チームが過負荷を知覚している場合は、優先順位を変更することで緊急の仕事を減らすことができ、プロジェクトの過負荷の原因に対処するための時間を作ることができます。

原文

If your work isn’t properly prioritized, every task can seem equally urgent, leading to both actual and perceived overload. In the case of actual overload, the urgency of tickets and alerts might cause team members to work until they resolve the problem, even if doing so means continuous long hours. When a team faces perceived overload, reprioritizing can help decrease the amount of urgent work, creating space for them to tackle the sources of overload through project work.

特定の状況を分析するときには、必ずしも作業負荷自体を変更する必要があるとは限りません。
代わりに、まずチームが直面している作業を定量化し、それが経時的にどのように変化したか(または変化しなかったか)を定量化することをお勧めします。たとえば、チームが処理するチケットとページの数で作業負荷を測定できます。作業負荷が時間が経っても変化していない場合、チームは過負荷を感じている理由は、単純に彼らが仕事に圧倒されているというだけなのかもしれません。
チームの現在の作業負荷をより包括的に把握したいなら、すべてのメンバーにすべての作業タスクを書き出してもらうよう依頼することで、1 回限りのスナップショットを収集できます。次に、組織の変更や優先順位の変更など、チームが直面する心理的ストレス要因を調べます。調査が終わったら、作業負荷の変更について決定を下すための一定の根拠を持つことができます。

原文

When analyzing your specific situation, you shouldn’t necessarily assume that the workload itself needs to change. Instead, we recommend first quantifying the work your team faces, and how it has (or hasn’t) changed over time. For example, you might measure workload by the number of tickets and pages the team handles. If your workload hasn’t actually changed over time, the team might feel overloaded simply because they perceive the work as overwhelming. To get a more holistic view of the team’s current workload, you can collect a one-time snapshot by asking every member to list all the work tasks they face. Then take a look at psychological stress factors your team faces, such as organizational changes or reprioritization. Once you’ve done your research, you have a stable basis for making decisions about changing the workload.

過負荷を軽減するための戦略 では、実際の負荷と知覚された負荷の両方を発見する方法について詳しく説明します。
まず、チームが過負荷状態にあることを認識し、それを軽減するための対策を講じた 2 チームのケーススタディを紹介します。

原文

Strategies for Mitigating Overload talks more about how to identify overload, both real and perceived. First, we present two case studies of teams that recognized that they were in overload and took steps to alleviate it.

ケーススタディー 1: チームの半分が退職したことによる過負荷(Case Study 1: Work Overload When Half a Team Leaves)

背景(Background)

Google の社内ストレージ SRE チームのある 1 チームは、Gmail、Google Drive、Google Groups などの複数のサービス、およびその他多くの社内向け・ユーザー向けサービスのバックエンドを担当していました。2016 年半ばに、最上級エンジニア(マネージャー)を含む チームの 3 分の 2 が、比較的短い期間内にチームから離脱したことで、危機が発生しました。このイベントは明らかに巨大な作業負荷管理の問題につながりました。同じ運用およびプロジェクト作業をカバーするための SRE の数が少ないため、すぐに過負荷に陥りました。また、各チームメンバーの専門知識がそれぞれ異なるプロダクト領域にサイロ化していたため、ボトルネックになっていました。新しいチームメンバーと 3 人のインターンを追加するとしても、長期的には作業負荷が改善できますが、増員時に、時間とエネルギーの多大な投資が必要だったでしょう。

原文

One of Google’s internal storage SRE teams was in charge of backends for multiple services, including Gmail, Google Drive, and Google Groups, and many other internal or user-facing services. We experienced a crisis in mid-2016 when two-thirds of the team—including the most senior engineer (the manager)—transferred to other opportunities within a relatively short window, for genuinely entirely unrelated reasons. This event obviously led to a huge workload management problem: fewer SREs available to cover the same operational and project work quickly resulted in overload. Our work was also bottlenecked because each team member’s expertise was siloed to a different area of production. While the addition of new team members and three interns would improve our workload in the long term, ramping up those engineers would take a serious investment of time and energy.

問題(Problem Statement)

上記の要因により、チームの生産性が大幅に低下しました。プロジェクトの仕事は遅れ始め、私たちが管理していた多くのサービスに関連するチケットがたまり始めました。優先順位の高いタスクを終わらせるのに手一杯で、このバックログを処理するための余裕はありませんでした。必要な重要かつ緊急の作業をすべて引き受けることができなくなるまでには、それほど長くはかからなかったでしょう。その一方で、私たちのチームはすぐにもっと優先度の高い仕事を受ける予定でした。

原文

The preceding factors significantly decreased team productivity. We started to fall behind on project work, and tickets related to the many services we managed began to pile up. We didn’t have the bandwidth to address this backlog, as all of our work was consumed by higher-priority tasks. It wouldn’t be long before we weren’t able to undertake all of the critical and urgent work we needed to. Meanwhile, our team was slated to receive more high-priority work soon.

もし私たちがいくつかの仕事を諦めなかったとしたら、重要な仕事を落とし始めるのは時間の問題だったでしょう。しかし、仕事の負担を軽減し始めるとすぐに、いくつかの心理的な障壁を感じました。

  • 進行中の作業を諦めた時、これまでの努力を無駄にしたように感じられます。バックログの大部分は、私たちにとって非常に重要または努力に値するもののように思えたので、プロジェクトを無期限にキャンセルしたり遅らせたりすることを正しいものだとは思えませんでした。私たちは、 サンクコストの誤謬 に陥っていることに気づいていませんでした。
  • プロセスの自動化や作業負荷の根本的な原因の修正に注力することは、優先順位の高い割り込みを即座に処理することほど重要ではありませんでした。この仕事がすでに巨大な山の頂上に追加されたとき、すべての仕事は途方もないもののように感じられました。

原文

If we didn’t move some work off our plate, it was only a matter of time before we accidentally began to drop important work. However, as soon as we started offloading work, we hit some psychological barriers:

  • Dropping any work that was in progress felt like we had just wasted our efforts. Most of the backlog seemed to be either critical or worth the effort to us, so it just didn’t feel right to cancel or delay projects indefinitely. We didn’t realize we were in the grip of a sunk cost fallacy.
  • Putting effort into automating processes or fixing the root cause of the workload was not as critical as immediately dealing with high-priority interrupts. When this work was added to the top of an already huge pile, all of the work felt overwhelming.

やろうとしたこと(What We Decided to Do)

チームを部屋に集め、プロジェクトのバックログ、運用作業、チケットなど、チームのすべての責任をリスト化しました。それから私たちはすべてのリストアイテムをトリアージしました。リストがホワイトボードにほとんど収まっていなくても、作業タスクを 1 つ 1 つ表示することで、実際の優先順位を特定して再定義することができました。その後、優先度の低い作業項目を最小限に抑える、引き渡す、または削除する方法を見つけることができました。

原文

We gathered the team in a room and listed all the team’s responsibilities, including project backlog, operational work, and tickets. Then we triaged every list item. Viewing every single one of our work tasks (even though the list barely fit on the whiteboard) helped us identify and redefine our actual priorities. We were then able to find ways to minimize, hand off, or eliminate lower-priority work items.

実行したこと(Implementation)

重要性は高くないが、デプロイ後の運用負荷を大幅に削減するような、簡単に実現できる自動化を発見しました。

原文

We identified low-effort automation that, while not critical, would significantly reduce operational load once deployed.

また、文書化によって利用者が自分自身で解決できるようになるようなな、一般的な問題も特定しました。お客様が必要としていた手順を書くのにはさほど時間はかからず、繰り返しの多い作業をキューから削除することができました。

原文

We also identified common problems that we could document that would enable self-service. Writing the procedures our customers needed didn’t take long, and removed some repetitive work from our queue.

我々は合理的に出来る限り多くのバックログチケットをクローズしました。チケットのほとんどは、すでに意味を失っていたり、重複していたり、または主張されているほど緊急ではないことが判明しました。一部のチケットでは、アクションに繋がらないような監視をしていたため、関連する監視を修正しました。場合によっては、致命的ではない問題にも積極的に取り組んでいました。もっと緊急のチケットに対応するために、それらの問題を一旦置くこともありましたが、それらの進歩は文書化されていたので、コンテキストを忘れることなくそれらの問題に再び取り組むことができました。

原文

We closed as many of our backlogged tickets as we reasonably could. Most of these tickets turned out to be obsolete, redundant, or not as urgent as they claimed. Some tickets were monitoring artifacts that were nonactionable, so we fixed the relevant monitoring. In some cases, we were actively addressing issues that weren’t critical. We set these issues aside to work on more urgent tickets, but first documented our progress so we wouldn’t lose context before we were able to work on them again.

重要性が疑わしいときは、タスクを諦めましたが、トリアージの第 2 段階としてマークしました。やることがほぼなくなったら、この暫定のリストを見直し、どのタスクを再開するかを決定しました。そして、インパクトのある、あるいは再開するのに十分なほど重要なタスクはほとんどないことがわかりました。

原文

When in doubt, we dropped a task, but marked it for a second phase of triage. Once our plates were (almost) empty, we revisited this tentative list to decide what tasks to resume. It turned out that almost none of these tasks were impactful or important enough to resume.

2 日間の集中トリアージと、1 日とプロセスと自動化の実装の文書化によって、小さなチームは数ヶ月にわたり邪魔されてきたバックログに取り組むことができました。それから本番環境における活発な問題に関連していた残りのいくつかの割り込みに対処することができました。

原文

In two days—one day of intensive triage plus one day of documenting processes and implementing automation—our much smaller team addressed a backlog of several months of interrupts. We could then deal with the few remaining interrupts, which were related to active issues in production.

教訓(Lessons Learned)

私たちのチームは、過負荷を特定して、そのスコープを絞ることが、過負荷を修正するための最初のステップであることを学びました。チームを健康な状態に戻すためには、全員を部屋に入れてバックログを再評価する必要がありました。

原文

Our team learned that identifying and scoping overload is the first step toward fixing it. We needed to get everyone in a room and reevaluate the backlog before we could help our team get back to a healthy state.

割り込みの新たな積み上げを避けるために、2 週間に 1 回割り込みの優先順位付けを開始しました。テックリードは定期的にタスクキューをチェックし、チームが過負荷になる危険性があるかどうかを評価します。過負荷を避けるために、チームメンバーは 10 以上のオープンチケットを担当しないことに決定しました。チームリーダーが、チームメンバーが 10 枚以上のチケットを持っていることに気付いた場合、以下の対策を実行できます。

  • 古くなったチケットを閉じるようにチームに思い出させる。
  • 過負荷のチームメンバーと同期し(対面で話し合い?)、それらからチケットをオフロードする。
  • 各チームメンバーに過負荷のメンバーのチケットキューに対処するように指示する。
  • チーム全体として、1日チケット修正に集中する日を設ける。
  • チケットの原因を修正するための作業、または将来のチケットを減らすための運用上の作業を割り当てる。

原文

In order to avoid a new pile-up of interrupts, we started triaging interrupts once every two weeks. Our technical lead periodically checks the task queue and evaluates whether the team is at risk of becoming overloaded. We decided that each team member should have 10 or fewer open tickets to avoid overload. If the team lead notices that team members have more than 10 tickets, they can do one or some combination of the following:

  • Remind the team to close out stale tickets.
  • Sync with overloaded team members and offload tickets from them.
  • Prompt individual team members to address their ticket queue.
  • Organize a team-wide one-day ticket fix-it.
  • Assign work to fix the sources of tickets, or operational work to reduce future tickets.

ケーススタディ 2:組織上および作業負荷の変更後に知覚された過負荷(Case Study 2: Perceived Overload After Organizational and Workload Changes)

背景(Background)

このケーススタディの Google SRE チームは、2 つの拠点に別れていて、各拠点に 6 人または 7 人のオンコールエンジニアがいました(チームのサイズについての詳細は、 SRE 本の第 11 章 を参照してください)。チューリッヒチームは過負荷でした。

原文

The Google SRE team in this case study was split between two locations, with six or seven on-call engineers at each site (for more discussion on team size, see Chapter 11 of Site Reliability Engineering. While the Sydney team was operationally healthy, the Zürich team was overloaded.

SRE本11章の内容抜粋

オンコールローテーションに必要な人数

  • 24/7のオンコールローテーションを維持するための最小人数
    • セカンダリを置かない場合: 4人
    • プライマリ・セカンダリ体制の場合: 8人
    • 2サイトチームの場合: 6 * 2 = 12人(この根拠は謎)

マルチサイトチームのメリット・デメリット

  • メリット
    • 全てのメンバーが夜間シフトを避けられる
    • プロダクションとの接点を持ち続けられる
      • 来るかわからないページャーをひたすら待機する...という時間がゼロになる
  • デメリット
    • コミュニケーションと調整のオーバーヘッドが発生する

チューリッヒチームが過負荷になる前は、安定していて、満足感がありました。管理していたサービスの多くは比較的安定していて、それぞれが多様で高度なメンテナンスでした。私たちがサポートしているサービスの SLO と外部の依存関係の SLO はミスマッチでしたが、それが問題を引き起こすことはありませんでした。管理しているサービスを改善するために、いくつかのプロジェクトに取り組んでいました(一例として、負荷分散の改善など)。

原文

Before the Zürich team went into overload, we were stable and content. The number of services we managed was relatively stable, and each was varied and high maintenance. While the SLOs of the services we supported were mismatched with the SLOs of their external dependencies, this mismatch hadn’t caused any issues. We were working on a number of projects to improve the services we managed (for example, improving load balancing).

同時に発生したい複数のイベントをトリガーとして、チューリッヒのチームは過負荷に陥りました。ノイズが多く、Google の一般的なインフラストラクチャにあまり統合されていない新しいサービスの導入に着手した時に、追加の作業負荷と知識不足の組み合わせが、より多くの問題を引き起こしました。

  • 新しいサービスと移行関連の監視が洗練されていなかったため、1 シフトあたりのページ数が増えました。増加は漸進的ため、過負荷になるまでページが増えていることに気づきませんでした。。
  • SRE は新しいサービスに無力感を感じていました。適切に対応するための十分な情報が得られていないため、開発チームに質問する必要がありました。過負荷になった場合、開発者にサービスを返却することが保証されていましたが、チームはサービスを返却したことがなかったため、これを実行可能なオプションとは考えませんでした。
  • 5 人という小規模なオンコールローテーションにより、通常の運用業務に費やす時間が多く取れませんでした。
  • 新しいシステムのチケット・アラートは、チームが変わる前に存在していた問題を表面化させました。それまではアラートを単純に無視していましたが、無視されたメールアラートをチケットに移動することが要求されました。プロジェクト計画の段階では、この新しい技術的負債の発生源を考慮に入れていませんでした。
  • 新しいチケット SLO では、3 日以内にチケットを処理する必要がありました。つまり、オンコール担当者は、オンコール中に作成されたチケットをより早く解決する必要がありました。3  この SLO は、(ほとんど無視されている)バックログに追加されるチケットの数を減らすことを目的としていましたが、さらに悪い副作用を引き起こしました。SRE は、フォローアップ作業に直ちに取り組む必要があるため、交代後に必要な休息を取ることができないと感じました。これらのチケットの優先順位が高いことで、SRE は他の運用作業に十分な時間を 使えませんでした。

原文

Simultaneous triggers sent the Zürich team into overload: we started onboarding new services that were noisier and less integrated into Google’s general infrastructure, and the technical lead manager and another team member left our team, leaving it two people short. The combination of the additional workload and knowledge drain triggered more problems:

  • Untuned monitoring for the new services and the migration-related monitoring resulted in more pages per shift. This buildup was gradual, so we didn’t notice the uptick as it occurred.
  • SREs felt relatively helpless with the new services. We didn’t know enough about them to react appropriately, and often needed to ask the development team questions. While the overload perhaps warranted handing a service back to developers, our team had never handed back a service, so we didn’t really consider this a viable option.
  • A smaller on-call rotation of five people cut into the hours we normally spent on operational work.
  • New ticket alerts were surfacing problems that existed before the recent team changes. While we had simply ignored these problems in the past, we were now required to move ignored email alerts to tickets. Project planning hadn’t taken this new source of technical debt into account.
  • A new ticket SLO required us to handle tickets within three days, meaning that on-callers had to resolve tickets created during their on-call shift much sooner.3 The SLO aimed to reduce the number of tickets being added to our (mostly ignored) backlog, but created a side effect that was perhaps even worse. Now SREs felt that they couldn’t get the rest they needed after a shift because they had to immediately tackle follow-up work. The higher priority placed on these tickets also meant that SREs didn’t have enough time for other operational work.

この間、2 つのチームを管理する新しいマネージャーがアサインされました。新しいマネージャーは、オンコールローテーションには加わっていなかったため、チームメンバーが経験しているストレスを直接感じませんでした。チームが状況をマネージャーに説明しても、何も変わりませんでした。チームメンバーはマネージャーが話を聞いてくれないと感じ、経営陣から遠く離れていると感じました。

原文

During this time, our team was assigned to a new manager who also managed two other teams. The new manager was not part of the on-call rotation and therefore didn’t directly feel the stress team members were experiencing. When the team explained the situation to the manager, nothing changed. Team members felt that they weren't being heard, which left them feeling distant from the management team.

チケットによる過負荷は数カ月間続き、チームメンバーは不機嫌になりました。それは、一連の不幸がチーム全体に広がるまででした。

原文

The overload from tickets continued for months, making team members grumpy, until a cascade of unhappiness spread across the team.

問題(Problem Statement)

2 人のメンバーを失い、追加のさまざまな仕事を受けた後、チームは過負荷を感じました。この気持ちを直属のマネージャーに伝えたところ、マネージャーは反対しました。長時間労働が続くに連れて、疲弊が始まりました。生産性が低下し、チームが解決できるよりも早くタスクが増え始めました。知覚された過負荷は今や客観的な過負荷となり、状況を悪化させた。

原文

After losing two people and receiving additional and varied work, our team felt overloaded. When we tried to communicate this feeling to our direct manager, the manager disagreed. As the long hours continued, exhaustion set in. Productivity was declining and tasks started accruing faster than the team could resolve them. The perceived overload now became objective overload, making the situation worse.

過負荷によって引き起こされた感情的なストレスは士気を低下させ、何人かのチームメンバーを燃え尽き症候群にしました。個人が過労による身体的影響(病気や生産性の低下)に対処するにつれて、チームの他の人々はより多くの仕事をしなければなりませんでした。毎週のチームミーティングで割り当てられた仕事は終わりませんでした。

原文

The emotional stress caused by overload was lowering morale and causing some team members to burn out. As individuals dealt with the physical effects from overwork (illness and lower productivity), other people on the team had to pick up more work. The work assigned in weekly team meetings wasn’t getting done.

その後、仕事を終わらせるにあたり誰も頼れないと考えるようになり、チーム内の信頼感と信頼性を低下させました。その結果、私たちは心理的安全の重要な要素である対人関係におけるリスクテイクについて安全であるとは感じませんでした( [SRE 本の  第 11 章を](https://landing.google.com/sre/book/chapters/being-on-call.html)。チームメンバーは、他のチームメンバーからの受容・尊敬を感じることができず、協力して何かをすることはありませんでした。チームの心理的安全性が低下すると、コラボレーションが停止し、情報共有が遅くなり、さらに非効率的になりました。

原文

We then started assuming we couldn’t depend on other people to get their work done, which eroded feelings of trust and dependability within the team. As a result, we did not feel safe about interpersonal risk taking, an important factor in psychological safety (see Chapter 11 in Site Reliability Engineering). Team members didn’t feel accepted and respected by other team members, so they didn’t freely collaborate with each other. As psychological safety diminished on the team, collaboration stopped, slowing down information sharing and causing further inefficiencies.

心理的安全性の喪失は、チーム調査でも明らかでした -- チームメンバーは、自分がチームに所属しているようには感じていないと述べました。彼らはもはや自分自身のキャリア開発を気にせず、チームの昇進率は史上最低にまで落ちました。

原文

Team surveys also revealed a loss of psychological safety—team members said they didn’t feel like they belonged on the team. They no longer cared about their own career development, and the promotion rate on the team dropped to an all-time low.

上級管理職が新しい全社的プロジェクトを私たちに割り当てたときに、ついにブレークポイントがきました。
このとき、新しいプロジェクトと過負荷について、マネージャー層と再び対話しました。一連の議論の結果、私たちの不幸な状況は単なる仕事の過多の結果ではないことが明らかになりました。

原文

We finally hit a breaking point when upper management assigned us new mandatory company-wide projects. At this point, we renewed our conversations with management about overload with renewed vigor. A series of discussions revealed that our unhappy situation wasn’t just a result of too much work—our perceptions of team safety led us to stop trusting and collaborating with each other.

やろうとしたこと(What We Decided to Do)

上級管理職は私達のチームに 3 チーム間(※訳注: なんか 1 チーム増えてる?)で共有されていない新しいマネージャーを割り当てました。新しいマネージャーは、チームの心理的安全性を向上させるために参加型マネジメントのスタイルを採用しました。この手法により、チームメンバーはチームの問題解決に積極的に参加することができます。私たちの直属のマネージャーを含むチーム全体が、私たちのチームの有効性を向上させるために一連の簡単なチームビルディング演習を行いました(そのうちのいくつかはお茶を一緒に飲むのと同じくらい簡単でした)。4その結果、私たちは一連の目標を作ることができました。

原文

Upper management assigned our team a new manager who wasn’t shared among three teams. The new manager used a participatory management style to improve psychological safety on the team so that we could once again collaborate. This method empowers team members to actively participate in solving team problems. The entire team, including our direct manager, engaged in a set of simple team-building exercises to improve the effectiveness of our team (some of which were as simple as drinking tea together).4 As a result, we were able to draft a set of goals:

短期

  • 健康的な職場環境を確立するために、ストレスを解消し、心理的安全性を向上させる。

中期

  • トレーニングを通じて個々のチームメンバーと信頼を築く。
  • 過負荷を引き起こしている問題の根本的な原因を見つける。

長期

  • カスケードの原因となっていた進行中の問題を解決する。

原文

Short term

  • Relieve stress and improve psychological safety to establish a healthy work atmosphere.

Medium term

  • Build confidence of individual team members through training.
  • Find the root cause of the issues that are causing overload.

Long term

  • Resolve ongoing problems that contributed to the cascade.

これらの目標を設定するために、我々は最初にチーム内でいくつかの心理的安全性を一定ラインにする必要がありました。士気が向上するにつれて、私たちは知識を共有し、お互いのアイディアを積み重ねて、作業負荷を管理する方法を見つけ出しました。

原文

In order to set these goals, we had to first achieve some kind of baseline psychological safety within the team. As morale improved, we began to share knowledge and build on each other’s ideas to figure out ways to get our workload under control.

実行したこと(Implementation)
短期的な取り組み(Short-term actions)

長期的なストレスは、過労・チームの安全性に対する認識のどちらが原因であっても、生産性を低下させ、人々の健康に影響を与えます。したがって、私たちの最も大切な短期的な取り組みは、ストレスを解消し、信頼と心理的安全性を改善することでした。いったんストレスから解放されると、チームメンバーはより明確に考え、チーム全体を前進させることに参加することができました。過負荷を認識してから 1 か月以内に、次のことを実施しました。

原文

Long-term stress, whether caused by overwork or perceptions of team safety, decreases productivity and impacts people’s health. Therefore, our most important short-term action was to provide stress relief and improve trust and psychological safety. Once relieved of some stress, team members could think more clearly and participate in driving the whole team forward. Within a month of identifying the overload, we implemented the following:

  • 問題を解消するための円卓会議をしました(ひし形のテーブルで)。チームはフラストレーションを解消し、過負荷の考えられる原因をブレインストーミングしました。
  • 負荷を測定するためのより良い測定基準を見つけました。ページ数の独自の測定基準を改善することにしました。私たちは、オンコール担当者にチケットを自動割り当てしました、そして、オンコール担当者は、シフトが終了した後でさえもこれらのチケットに対して責任がありました。私たちの新しい測定基準はオンコール担当を交替した後にオンコール担当者がチケットを解決するのに必要な時間を測定しました。
  • スパムアラートを審査し、削除しました。アラートを確認し、ユーザーが直面している問題を表すことのないアラートを削除しました。
  • 厳密な方法でなくても、とりあえずアラートを沈黙させる。チームは意図的にすべてのアラートの原因を見つけようとはしませんでしたが、すでに知られている問題についてはページングやチケットの発行からストレスを軽減することに集中しました。以下の戦略を使用しました。

    • 表面化したアラートは修正されるまで沈黙させる。
    • アラートは、限られた期間(通常は 1 日、場合によっては 1 週間まで)しか沈黙させることができない。この制約がないと、サービスの停止まで隠されてしまうかもしれない。
    • 数分以内に修正されなかったアラートは、チケットとしてアサインされる。
  • 1 チーム専用の直属のマネージャーを追加しました。尊敬されるチームメンバーを新しいマネージャーにすることで、マネジメントに対する信頼が再確立されました。3 チームを管理するのではなく、新しいマネージャーは個々のチームとそのメンバーに、より多くの時間を注ぐことができました。

  • チームのバランスを取り戻しました。チームや組織についての先入観がない技術的に経験の豊富な SRE を追加することで、新しい視点とオンコールの安心感がもたらされました。適切な人を見つけることは決して簡単な作業ではありませんでしたが、その努力は報われました。

  • ランチやボードゲームセッションなどのチームイベントを開催しました。仕事に関係のないトピックについて話したり、一緒に笑ったりすることでチームの緊張が緩和され、心理的安全性が向上しました。

原文
  • Started a semiregular round table to discuss issues. The team released frustration and brainstormed possible causes of the overload.
  • Found a better metric for measuring load. We decided to improve upon our original metric of number of pages. We auto-assigned tickets to on-callers, and the on-caller was responsible for these tickets even after their shift ended. Our new metric measured how much time an on-caller needed to resolve a ticket after their shift.
  • Audited and removed spamming alerts. We reviewed alerts and removed the ones that didn’t represent user-facing problems.
  • Silenced alerts generously. The team deliberately didn’t try to find the source for every single alert, but focused on relieving the stress from being paged and ticketed continuously for issues we already knew about. We used the following strategy:

  • Alerts that surfaced were silenced until they were fixed.

  • Alerts could be silenced only for a limited period of time (typically a day, sometimes up to a week). Otherwise, they might mask outages.

  • Alerts that couldn’t be fixed within a few minutes were assigned to a tracking ticket.

  • Added a direct manager dedicated to a single team. Making a well-respected team member the new manager reestablished trust in management. Rather than managing three teams, the new manager could focus more time on the individual team and its members.

  • Rebalanced the team. We introduced a new perspective and on-call relief by adding technically experienced SREs that didn’t have preconceptions about the team or organization. Finding appropriate people was by no means an easy task, but was well worth the effort.

  • Instituted team events like lunches and board game sessions. Talking about non-work-related topics and laughing together eased tension on the team and improved psychological safety.

中期的な取り組み(Mid-term actions)

短期的な解決策だけでは健全な雰囲気を維持することはできません。たとえば、私たちの短期的な戦術の 1 つは、実際に原因を修正せずにアラートを黙らせることでした。3 か月以内に、私たちは以下の行動も取りました。

  • チームが恒久的な修正とプロジェクト作業に集中できるように、 運用作業の時間を可能な限りオンコール中のみに制限しました (SRE 本の  第 29 章を参照)。
  • あるサービスの責任を開発チームに返しました。
  • お互いに対して(そして新しいチームメンバーに対しても)、トレーニングを行いました。トレーニングには時間とエネルギーの投資が必要ですが、知識を広めることは、将来的にすべてのチームメンバー(および将来の被雇用者)が問題をより迅速にトラブルシューティングして修正できることを意味します。同僚をトレーニングすることは自信を高めることにも繋がりました。なぜなら、実際のところ、私たちはサービスについてかなり知っていることに気づいたからです。彼らが知識を得るにつれて、チームメンバーはサービスを管理し、彼らの信頼性を向上させそして過負荷を減らすための新しい方法を見つけ始めました。
  • リモートチームから SRE を派遣し、チームのオンコールシフトの一部を担当し、トレーニングに参加してもらいました。彼らはチームへの負担に気付き、いくつかの貴重な新しいパースペクティブを提供しました。
  • 欠員 2 名を埋め戻しました。
  • 沈黙が期限切れした時に各アラートに対処しました。私たちは、繰り返し飛んでくるページや、アクションに繋がらないページについて、毎週のプロダクションミーティングでは話し合いました。これにより、アラートの調整や根本的な問題の修正を行うことができました。これらは重要な(そして明白な)行動でしたが、それまではアラートが沈黙し、一定のノイズが発生しないようにしなくなった時に、分析し、アクションを行う以上のことはできていませんでした。
  • ヒアリングを実施するマネジメント(上級マネージャーおよびチームリーダーを含む)は、チームの問題点に耳を傾け、チーム主導のソリューションを見つけることを意識的に試みました。
  • パースペクティブを追加しました。希望は戦略ではありませんが、それは確かにチームの士気を高めるのに役立ちます。新しいメンバーがオンコールローテーションに参加すること、より明確な優先事項に移行すること、そしてノイズを発生させるプロジェクトが終了することを約束することで、チームの雰囲気は向上しました。

原文

Short-term solutions alone wouldn’t sustain a healthy atmosphere—for example, one of our short-term tactics was to silence alerts without actually fixing the cause. Within three months, we also took the following actions:

  • Limited operational work to on-call time as much as possible (see Chapter 29 in Site Reliability Engineering) so the team could concentrate on permanent fixes and project work.
  • Returned responsibility for one service back to its development team.
  • Trained each other (and new team members). While training requires an investment of time and energy, disseminating knowledge meant that all team members (and future hires) could troubleshoot and fix issues more quickly in the future. Training coworkers improved our confidence, because we came to realize that we actually knew quite a bit about the services. As they gained knowledge, team members started to find new ways to manage services, improving their reliability and reducing overload.
  • Brought in SREs from the remote team to staff some of our on-call shifts and participate in training. They noticed the strain on the team and provided some valuable new perspective.
  • Backfilled the two open roles on the team.
  • Tackled each alert as the silences expired. We discussed repetitive pages and pages that resulted in no action at length in the weekly production meeting, which led us to tune alerts and/or fix the underlying problems. While these were important (and obvious) actions, we only had the space to analyze and take action once the alert was silenced and not creating constant noise.
  • Organized listening events. Management (including the skip-level manager and team leads) made a conscious effort to listen to the team’s pain points and to find a team-driven solution.
  • Added perspective. Hope is not a strategy, but it certainly helps team morale. With the promise of new members joining the on-call rotation, a shift to clearer priorities, and an end to noise-generating projects, the team’s mood improved.

長期的な取り組み(Long-term actions)

新たな安定性を維持するために、これまで管理してきたサービスの SLO を新しいサービスのバックエンドの SLO と同水準にして、サービス群をより均一にしようとしています。
均一性には 2 つの利点があります。SRE の認知的負荷が軽減され、複数サービスで使用可能な自動化の記述が容易になります。
私たちはまた、長い間使われてきたサービスを見直し、それらを現在の本番環境のスタンダードへとアップデートしています。たとえば、一部のサービスは、長年にわたって負荷が大幅に増加したため、うまく機能していません。一部のサービスは、それらのバックエンドサービスのポリシーの変更が行われるたびに更新する必要があります。シンプルに数年間更新が内容なサービスもあります。

原文

To help maintain our newfound stability, we are currently aligning our SLOs with the SLOs of their service backends, and working toward making the services more uniform. Uniformity has a double benefit: it decreases cognitive load for SREs and makes it easier to write automation that can be used across services. We’re also reviewing services that have been around for a long time and updating them to current production standards. For example, some services are operating poorly under load that’s increased significantly over the years. Some services need to be updated per changes to their backend services’ policies. Other services simply haven’t been updated for several years.

Effects

最初のブレインストーミングの数か月後、取り組みが実を結びました。オンコール中のシフトがより静かになり、チームはグループとして共同で困難なインシデントに迅速かつ効率的に対処できるようになりました。それから少し後、新しいチームメンバーが到着しました。円卓会議で心理的安全性について話し合ったとき、新しいメンバーは、チームがそのような問題を抱えていることを想像できないと言いました。実際、チームメンバーはチームを暖かく安全な職場と見なしていました。当初のエスカレーションから約 1 年後、当初の過負荷はほとんど残っておらず、匿名の調査では、チームメンバーはチームが効果的かつ安全であると感じたことがわかりました。

原文

A few months after our first brainstorming meeting, results began to surface: on-call shifts became quieter, and our team managed to quickly and efficiently deal with a difficult incident collaboratively as a group. A bit later, new team members arrived. When we discussed psychological safety during a round-table session, the new members said they couldn’t imagine that the team ever had such problems. In fact, they saw our team as a warm and safe place to work. About one year after the original escalation, little of the original overload remained and an anonymous survey showed that team members now felt the team was effective and safe.

教訓(Lessons Learned)

職場の変化はチームの人々に心理的影響を与える可能性があります - 結局のところ、あなたのチームメイトは機械ではありません。あなたがチームのストレスレベルに注意を払うことで、人々はお互いに協力し合うのに十分な信頼を得ます。それを怠ると、チームはストレスを引き起こす過負荷の悪循環に入る可能性があります。

原文

Workplace changes can have a psychological impact on the people on the team—after all, your teammates are not machines. You need to attend to the team’s stress levels so that people start trusting each other enough to work together; otherwise, the team can enter a vicious cycle of overload that causes stress, which in turn prevents you from tackling overload.

知覚された過負荷  、事実上の過負荷であり、他の要因によって引き起こされる作業過負荷と同じくらいチームに大きな影響を与えます。シドニーの姉妹チームは同じ問題を経験しませんでしたし、見つけたページの数は実際には前年と比べてそれほど変わっていませんでした。代わりに、2 人のチームメンバーの喪失、認知的負荷の増加、チケットの騒音の増加、およびチケットの新しい 3 日間の SLO により、チームは過負荷を認識するようになりました。結局、客観的な負荷と知覚された過負荷の違いは問題ではありませんでした。少数のチームメンバーの過負荷がチーム全体の過負荷にすぐにつながる可能性があります。

原文

Perceived overload is, in fact, overload, and has as much impact to a team as work overload caused by other factors. In our case, our sister team in Sydney didn’t experience the same issues, and the number of pages we fielded didn’t actually change very much compared to previous years. Instead, the loss of two team members, increased cognitive load, increased ticket noise, and a new three-day SLO on tickets led the team to perceive overload. In the end, the difference between objective and perceived overload didn’t matter: the perceived overload of a few team members can very quickly lead to overload for the whole team.

過負荷を軽減するための戦略(Strategies for Mitigating Overload)

チームが過負荷になったときに、外部の観点から非常に簡単に認識できる場合があります。同様に、振り返ってみるとどのような行動が取られるべきであったかについてコメントするのは簡単です。
しかし、過負荷の真っ最中で、どのように過負荷を認識すれば良いのでしょうか?健康で、友好的で、幸せな職場環境への道は、過負荷に悩んでいるときには視覚化するのが難しい場合があります。このセクションでは、チームの過負荷を特定して軽減するためのプラクティスについて説明します。

原文

An outside perspective can sometimes quite easily identify when a team is overloaded. Similarly, it’s easy to comment on what actions should have been taken in retrospect. But how do you identify overload when you’re in the middle of experiencing it? The path toward a healthy, friendly, and happy work atmosphere can be hard to visualize when you’re mired in overload. This section describes practices for both identifying and mitigating overload on your team.

過負荷の症状を認識する(Recognizing the Symptoms of Overload)

過負荷の症状を知っていれば、過負荷のチームを特定するのはとても簡単です。

チームの士気の低下

  • 過負荷は暴言や苦情として現れるかもしれません。関連するトピック(仕事の条件、仕事の満足度、プロジェクト、仲間、および管理職)に関する調査は通常、チームの士気を反映し、チームが過負荷になるとより悪い結果をもたらします。チームリーダーとの定期的なアクティブリスニング を行う時間を取ることで、あなたが気付いていない問題を発見することができます。アクティブリスニングの本質は、判断なしに聞くことです。

チームメンバーが長時間勤務している、および/または病気のときに勤務している

  • 補償なしで残業することは、心理社会的ストレス要因になり得ます。指導者は良い例を示すべきです:契約した時間に労働し、病気のときは家にいましょう。

より頻繁な病気[5](http://landing.google.com/sre/workbook/chapters/overload/&xid=25657,15700021,15700186,15700190,15700253,15700256,15700259&usg=ALkJrhhWrIPq9r874sxNY3BCMeAkgiRwlA#ch17fn5

  • 過労のチームメンバーは、疲れ果てて病気になりがちです。

異常なタスクキュー

  • チームのタスクキューを定期的に確認して、バックログされているチケットの数、どの問題に対処しているのか、どのタスクを遅延またはドロップできるのかを確認することをお勧めします。チームが期限を守っていない場合、または緊急事態が原因でこの確認を定期的に実行できない場合、チームは予定よりも早く割り込みを累積する可能性が非常に高いです。

不均衡な指標

  • いくつかの重要な指標は、チームが過負荷であることを示している可能性があります。
    • 1 つの問題を解決するための長い期間
    • Toil に費やした時間の長さ
    • オンコール中のセッションから発生した問題を解決するまでの日数が多い

原文

It’s pretty easy to identify an overloaded team if you know the symptoms of overload:

Decreased team morale

  • Overload might manifest as rants and complaints. Surveys on relevant topics (job conditions, work satisfaction, projects, peers, and managers) usually reflect team morale and yield more negative results when a team is overloaded. Regular active listening sessions with team leaders can surface issues that you weren’t aware of. An essential element of active listening is to listen without judgment.

Team members working long hours, and/or working when sick

  • Working overtime without compensation can be a psychosocial stressor. Leaders should set a good example: work contractual hours and stay home when sick.

More frequent illness5

  • Overworked team members tend to get run down and sick more often.

An unhealthy tasks queue

  • We recommend regularly reviewing your team’s tasks queue to see how many tickets are backlogged, who is dealing with which issues, and what tasks can be delayed or dropped. If the team is missing deadlines, or if urgent matters prevent you from performing this review regularly, the team is very likely accumulating interrupts faster than it can attend to them.

Imbalanced metrics

  • A few key metrics might indicate that your team is overloaded:
    • Long time periods to close a single issue
    • High proportion of time spent on toil
    • Large number of days to close issues originating from an on-call session

チームは協力してどのような方法を使用するかを決定する必要があります。万能なアプローチはありません。各チームの過負荷はさまざまな方法で反映されます。
マネージャーは、各個人の作業負荷や作業習慣を把握せずにチームに方法論を押し付けないでください。。特定の方法を使用することを主張した場合、チームメンバーがマネージャーが作業が理解していないと感じるかもしれません。たとえば、問題を解決するのにかかる日数で負荷を評価する場合、問題を解決するために 1 日中作業が行われたり、作業を数日間にわたって分散されたりすることがあります。

原文

The team should work together to decide what measures to use. There is no one-size-fits-all approach; every team’s overload is reflected in different ways. As a manager, don’t impose a measure on the team without getting an idea of each individual’s workload and work habits. Team members might feel that you don’t understand the work if you insist on using a specific measure. For example, if you’re evaluating load by the number of days it takes to fix an issue, one person might work a full day fixing an issue, while another person might distribute the work across several days, along with other work.

過負荷を軽減しチームの健康を取り戻す(Reducing Overload and Restoring Team Health)

ここまで読み終えたら、あなたのチームはすでに過負荷になっていると思うかもしれません。絶望しないでください。このセクションでは、チームを元の状態に戻すためのアイデアの一覧を示します。

原文

After reading through the criteria, you might think your team is already overloaded. Don’t despair! This section provides a list of ideas to get your team back to a healthy state.

一般に、チームメンバーにもっとコントロールとパワーを与えることで、知覚された過負荷を減らすことができます。6マネージャーはストレスの多い状況ではマイクロマネジメントしたくなるかもしれませんが、パフォーマンスと仕事の満足度のレベルを上げるためにチームをループに入れて優先順位付けに取り組むことが重要です。7このモデルは、経営陣とチームメンバー間、およびチームメンバー間に(少なくとも)ある程度健全な関係がある(機能チームのベースライン)を想定しています。

原文

In general, giving team members more control and power reduces perceived overload.6 While managers might be tempted to resort to micro-management in stressful situations, it’s important to keep the team in the loop and work on prioritization together in order to increase the level of performance and job satisfaction.7 This model assumes baseline of a functional team, where you have (at minimum) a somewhat healthy relationship between management and team members, and between team members.

心理的ストレス要因の特定と軽減(Identify and alleviate psychosocial stressors)

機能不全のチームを修正することになると、何よりもまず、個々のチームメンバーは心理的安全性の感覚を取り戻す必要があります。その個々のメンバーが良くならないと、チームも良くなりません。

原文

When it comes to fixing a dysfunctional team, first and foremost, individual team members need to regain their sense of psychological safety. A team can function only as well as its individual members.

あなたは、各個人およびチーム全体の心理的ストレス要因を特定し、軽減することから始めることができます8 。これらの要素のうち、実際に管理しているものはどれですか。チームメンバーが大きな病気にかかっているかどうかを制御することはできませんが、チームのバックログのサイズ(ケーススタディ 1)やページのうるささ(ケーススタディ 2)は制御できます。

原文

You can start by identifying and alleviating psychosocial stressors8 for each individual and the team as a whole. Which of these factors do you actually have control over? You can’t control whether or not a team member has a major illness, but you can control the size of your team’s backlog (as seen in Case Study 1) or silence pages (as in Case Study 2).

あなたのパートナーであるプロダクト開発チームと連絡を取り、あなたのチームが過負荷であることを彼らに知らせてください。彼らは手を差し伸べること、思いやりを提供すること、あるいはプロジェクト全体を引き継ぐことさえできるかもしれません。

原文

Communicate with your partner product developer teams, and let them know your team is overloaded. They might be able to give a helping hand, provide compassion, or even take over entire projects.

あなたのチームメンバーが互いに頼りにして、ある程度の心理的安全性を得たとき、個々チームメンバーにより多くの責任を与えることができます(彼らが対人関係のリスクを負うことができるように)。専門分野を明らかにし、要員や技術的なリードを特定のテクノロジに割り当てることで、自信が高まり、リスクを負うことが可能になります。

原文

When your team members rely on each other and achieve a certain level of psychological safety (such that they’re able to take interpersonal risks), you can give more responsibility to individual team members. Uncovering areas of expertise and assigning point people and technical leads to specific technologies increases their self-confidence and therefore enables them to take risks.

意思決定は透明で、可能であれば民主的であるべきです。各チームメンバーは、状況をコントロールしている感覚を持つべきです。たとえば、ケーススタディ 2 のブレーンストーミングセッションは、チームが問題を特定し議論するのに役立ちました。

原文

Decision making should be transparent and, if possible, democratic. Each team member should have a feeling of control over the situation. For example, the brainstorming session in Case Study 2 helped the team identify and discuss issues.

四半期に1回、優先順位づけを行う(Prioritize and triage within one quarter)

健全なチームは問題に優先順位を付けて問題を切り分けることができます。ケーススタディ1は、この演習の好例です。チームは部屋に集まり、彼らのバックログを確認しました。レビューは彼らが彼らが過負荷であることを理解するのを助けました。彼らは自分たちの仕事に優先順位を付け、過負荷の一部を素早く軽減するタスクに取り組みました。ケーススタディ2のチームは、各四半期の終わりに集まって、既存の作業と将来の作業を一緒に計画し、優先順位を付けます。

原文

A healthy team can prioritize and triage issues. Case Study 1 provides a good example of this exercise: the team sat together in a room and reviewed their backlog. The review helped them realize they were overloaded. They reprioritized their work, and worked on the tasks that would quickly reduce some of the overload. The team in Case Study 2 now meets at the end of each quarter to plan and prioritize existing and future work together.

可能であれば、SRE が予定表に割り込みのない時間(オンコールもなし)をスケジュールして、自動化の開発や割り込みの根本原因の調査など、困難な性質を持つ作業に取り組む時間があるようにすることをお勧めします。ケーススタディ 2では、リモートチームがオンコールにいくらかの安心を与えた結果、チームメンバーはプロジェクトに注力する貴重な時間を得ることができました。

原文

If possible, we recommend that SREs schedule interrupt-free time (no on-call) on their calendars, so that they have time to work on qualitatively difficult tasks like developing automation and investigating the root causes of interrupts. In Case Study 2, when the remote team gave the on-call some relief, team members then had precious time to focus on their projects.

どうしても必要な場合は、作業をやめてください。ケーススタディ2では、チームはこの責任を開発チームに返すことで、いくつかのサービス対するオンコールサ対応を中止しました。

原文

If absolutely necessary, drop work: in Case Study 2, the team dropped on-call support for one of their services by returning this responsibility to the development team.

未来の自分を守る(Protect yourself in the future)

チームの作業負荷を評価するための指標を確立することを強くお勧めします。測定基準を定期的に見直して、適切なものが測定されていることを確認します。

原文

We strongly recommend establishing metrics to evaluate the team’s workload. Regularly review the metrics to make sure they are measuring the right things.

チームが過負荷から脱却したら、根本的な問題を監視または解決するための対策を講じることで、将来の過負荷を防ぐことができます。たとえば、ケーススタディ 1 のチームは、増え続ける未処理のタスクを検出するための軽量トリアージプロセスを維持しています。ケーススタディ 2 のチームは現在、バックエンドとサービスの SLO を調整するための長期計画に取り組んでいます。

原文

Once your team emerges from overload, you can prevent future overload by taking steps to monitor or resolve the underlying problems. For example, the team in Case Study 1 now maintains a lightweight triage process to detect a growing backlog of tasks. The team in Case Study 2 is currently working on a long-term plan to align backend and service SLOs.

あなたのチームが過負荷状態にあるときは、あなたが過負荷状態でなかった場合よりもさらに多くのことに繰り返しの労力を払うプロジェクト作業を優先します。あなたは将来利益を得ます。

原文

When your team is in overload, prioritize project work that pays down repetitive toil even more than you would if you weren’t overloaded. You will profit in the future.

最後に、チームの全員が、過負荷状態の可能性があることを示す早期アラートサインに責任を負うべきです。(過負荷の症状の認識 を参照)チームが過負荷に向かっていると感じたら、マネージャーは対面で腰を据えてチームメンバーと話をします。

原文

Finally, everyone on the team should feel responsible for the early warning signs (see Recognizing the Symptoms of Overload) that indicate a possible overload situation. Managers should sit down and talk with team members if they feel that the team is moving toward overload.

まとめ(Conclusion)

完璧な世界では、SREチームはSRE本で説明されている戦略でいつでも割り込みを管理することができます。しかし、私たちは人間なので、時には私たちのチームがその理想に到達しないことがあります。この章では、過負荷によってチームが消耗する可能性があるケースのいくつかを検討し、それを検出して対処する方法について説明しました。

原文

In a perfect world, SRE teams would always be able to manage interrupts with the tactics described in our first book. But we’re only human, and sometimes our teams don’t reach that ideal. This chapter examined some of the ways that overload can consume a team and discussed how to detect and respond when it does.

特に運用作業では、過度の割り込みが発生すると、チームは通常の作業負荷から過負荷に陥ることがあります。頻繁な割り込みは過負荷につながる可能性があり、過負荷は健康と生産性に悪影響を及ぼす。過負荷はチームメンバーに心理社会的ストレスを生み出し、それがさらに仕事に影響を及ぼし、自己実施サイクルを引き起こします。

原文

Particularly when it comes to operational work, excessive interrupts can very easily cause a team to slip from a normal workload to overload. Frequent interrupts can lead to overload, and overload negatively affects health and productivity. Overload creates psychosocial stressors for team members, which impacts work even further, causing a self-enforcing cycle.

知覚された過負荷は、労力や運用上の作業の量では測定できない特別な形の過負荷です。特定して排除するのは困難です。

原文

Perceived overload is a special form of overload that can’t be measured by the amount of toil or operational work. It is hard to pinpoint and to eliminate.

チームの作業負荷のバランスを保つためには、(知覚的または非知覚的な)過負荷を常に監視することが重要です。あなたのユーザーにより良いサービスを提供し、良い仕事をするためには、まず自分とあなたのチームに敬意を示す必要があります。毎日の仕事で健康的なバランスを保つことは、あなたとあなたのチームがその目標を達成するのを助けるのに大いに役立ちます。

原文

In order to keep a team’s workload in balance, it’s important to constantly monitor (perceived or nonperceived) overload. To better serve your users and do good work, you need to first show respect to yourself and your team. Maintaining a healthy balance in your daily work goes a long way in helping you and your team accomplish that goal.

原文

1Kara A. Latorella, Investigating Interruptions: Implications for Flightdeck Performance (Hampton, VA: Langley Research Center, 1999), https://go.nasa.gov/2Jc50Nh; NTSB, Aircraft Accident Report: NWA DC-9-82 N312RC, Detroit Metro, 16 August 1987 (No. NTSB/AAR-88/05) (Washington, DC: National Transportation Safety Board, 1988), http://libraryonline.erau.edu/online-full-text/ntsb/aircraft-accident-reports/AAR88-05.pdf*.

2Emmanuelle Brun and Malgorzata Milczarek, Expert Forecast on Emerging Psychosocial Risks Related to Occupational Safety and Health (Bilbao, Spain: European Agency for Safety and Health at Work, 2007), https://osha.europa.eu/en/tools-and-publications/publications/reports/7807118; M. Melchior, I. Niedhammer, L. F. Berkman, and M. Goldberg, “Do Psychosocial Work Factors and Social Relations Exert Independent Effects on Sickness Absence? A Six-Year Prospective Study of the GAZEL Cohort,” Journal of Epidemiology and Community Health 57, no. 4 (2003): 285–93, https://jech.bmj.com/content/jech/57/4/285.full.pdf*.

3For context, according to estimates, an SRE needed at least one additional day of ticket follow-up per shift.

4We used the Google program based on Project Aristotle: https://bit.ly/2LPemR2.

5Kurt G. I. Wahlstedt and Christer Edling, “Organizational Changes at a Postal Sorting Terminal—Their Effects Upon Work Satisfaction, Psychosomatic Complaints and Sick Leave,” Work and Stress 11, no. 3 (1997): 279–91.

6Robert A. Karasek Jr., “Job Demands, Job Decision Latitude, and Mental Strain—Implications for Job Redesign,” Administrative Science Quarterly 24, no. 2 (1979): 285–308.

7Frank W. Bond and David Bunce, “Job Control Mediates Change in a Work Reorganization Intervention for Stress Reduction,” Journal of Occupational Health Psychology 6, no. 4 (2001): 290–302; Toby D. Wall, Paul R. Jackson, and Keith Davids, “Operator Work Design and Robotics System Performance: A Serendipitous Field Study,” Journal of Applied Psychology 77, no. 3 (1992): 353–62.

8Brun and Malgorzata, Expert Forecast.

リンク

原文
Google 翻訳(便利)

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.