GitHub ActionsでTerraformのCI/CDをやってみた
kurochan
デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
システム運用のスキルトランスファー
shimo
最近知り合いがYouTubeでゲーム実況を始めたのにインスパイアされて、社内のDiscordで独り言を配信しているMMMの下條です。
最近以下のブログ記事を見つけました。
属人化してしまった現場において、システム運用スキルをどうシェアするかという難しい問題
私がまさに現状同じような状況に置かれており、試行錯誤している最中なのですが、私も同じ意見に行き着こうとしていた部分もあり、示唆に富む内容でした。
もともと私がメインでシステム開発・保守に関わっていたプロジェクトにおいて、運用の属人化を防ぐため、これまでのアプローチとして以下の2点を重視しながら運用スキルトランスファーを進めていました。
- 手順のドキュメント化
- 複数人での作業
これらは機能していた部分もあり、機能していなかった部分もあります。私自身の意識の問題もあるとは思いますが、それぞれについて仕組みとしての問題点を上げてみます。
1. 手順のドキュメント化の問題点
手順のドキュメント化はいい仕組みではありますが、以下の問題があります。
-
手順書を完璧にするにはコストがかかる。
単純な作業であればよいのですが、ある程度複雑な作業になると様々なケースの考慮が必要で、ドキュメント化自体が大変です。 -
障害対処などはケースが複雑。
前者とも関連しますが、運用作業でなく障害対処の場合は対応方法がパターン化するのが難しく手順書が複雑になってしまう場合があります。 -
手順書通りにオペレーションするだけではスキルアップになりにくい。
手順書がある状態で、新規メンバーに手順書通りにオペレーションしてもらうこともあったのですが、単なるオペレータを養成してしまうことにもなりかねません。現状では弊社の運用チームのメンバーには単なるオペレータとしての役割は求められておらず、きちんと考えながら作業できることが必要です。 -
手順書が古くなる場合もあり、完全に手順書通りのオペレーションをすればよいとは限らない。
ドキュメントは古くなる場合があります。単純に手順書をなぞるだけのオペレータになってしまうと、古くなった手順に気づかず、事故を起こしてしまう場合があります。
特に前者のドキュメント化のコストについてはかなりの工数が取られる場合もあり、つい面倒でドキュメント化をしなかったりすることがあったことも事実です。
複数人で作業の問題点
しばしば、新規メンバーにいきなりドキュメントを見ながらオペレーションをしてもらうような運用をしていたのですがこれには以下の問題があります。
-
作業に時間がかかってしまう。
二人でやれば工数は実質倍以上となってしまいます。そのため、急ぎのときなど、つい自分がサクッと済ませてしまいがちになるという問題がありました。 -
新規メンバーが既存メンバーのスキルを盗む機会が少ない。
新規メンバーにオペレーションをしてもらうだけでは、既存メンバーがどのように思考し、オペレーションをしているかの機会が少なくなってしまいます。
これらを踏まえると、手順書 (ドキュメント) を書くことにあまりコストはかけず、個々の底力を上げていくことで運用に対応できる強い組織づくりをしたほうがよいのではないかというのが、今の私の意見です。
※大きな組織であれば事情は異なり、よりドキュメントを重視することになると思いますが。
そして、最初に上げたサイトに書いてあったような、スキルを盗んでいくいわゆる寿司職人方式は、個々のスキルを上げる目的に対して、かなりいい方法なのではないかと感じています。ただし、その一方で実際に手を動かすことも重要であり、寿司職人方式から次第に手を動かしてもらう方向にシフトする方向がいいのではと考えています。
なお、寿司職人方式を実施する際に重要なこととして、
- 教える側は自分の思考など説明しながらオペレーションする。
- 教わる側はついていけない部分があれば質問して理解する。
ことが重要です。教える側のオペレーションが速すぎて結果的に理解できなかったみたいになっては意味がないですので。
また、ドキュメントについては何を書くべきかという問題にも行き着きますが、運用タスクであれば
- 作業の目的
- 大まかな手順
あたりを工数をかけない形で書いていくのがよいと考えています。
なお、システム運用のスキルトランスファーにおいては、大きく2つの観点でのスキルトランスファーがあると考えています。
- プロジェクト・プロダクトのナレッジ
- オペレーションに関するナレッジ (OSやネットワークなどのスキル・知識など)
後者のスキルを既に持っているメンバーであれば前者だけのスキルトランスファーになってくるので比較的実施しやすいのですが、同時に両方の観点でのスキルトランスファーを実施するのはなかなか難しいものです。後者についてはプロジェクトに関わらないスキルアップなどの取り組みは実施していますが、今後も継続してより良い方法を探っていきたいと考えています。
AUTHOR
