はじめに
次のようなシナリオを想像してほしい。小さなウェブ企業が問題にぶつかり始めている。ウェブサイトにひずみが出てきており、未だかつてない成長のためにしょっちゅうエラーを起こしている。新しい機能を実装してデプロイしようとしているのに、サービスの保守に時間を食われる。そのため、社員はだんだん不満を溜めてきている。グローバルに分散しているチームのあいだでは、言語やタイムゾーンの違いが対立の原因になっている。サイトがサービス障害を起こしたときの緊張したやり取りから非難だらけな(非難の応酬がある)文化が広がり始めており、他のチームを信頼せずチーム間の透明性が失われてきている。
この企業は、このような問題を解決するにはdevopsというものがよさそうだと考える。経営陣は、新しいdevopsチームをつくり、そこに新たに社員を採用する。devopsチームはオンコール(勤務時間外の電話呼び出し)に対応しなければいけない。従来の運用チームは、自分たちでは問題に対処できないときに、devopsチームのメンバーにエスカレーションするのである。devopsチームのメンバーは、運用チームのメンバーよりも経験が長く、彼らのほうが本番システムで起きた問題をうまく処理できる力を持っている。しかし、運用チームのメンバーは、新しいスキルを学ぶ時間と機会がないために、同じ問題を繰り返しエスカレーションしてくる。
devopsチームは、開発と運用の橋渡し役を務めるのに疲弊してくる。どのチームも、他のチームの計画立案プロセス、メール、チャットメッセージはもちろん、バグトラッカーのことも知らない。経営陣の「ソリューション」は、非難文化を取り除くどころか、単に誤解を倍増させただけである。
そこで、経営陣は「このdevopsなるもの」は失敗であり、これ以上運用にもdevopsにも時間と労力、資金を投下しないと宣言する。彼らは、「サイトを落とし続け」、「本物の」開発作業の「邪魔をする」無能な人たちだとされてしまう。まともな職を見つけられる人は退職して、職場習慣として非難や怒号が認められていない別の企業に移る。そのため、残されたチームはもっと無能になる。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access