シカゴを拠点にディジタルマーケティング用プラットフォームを提供するCentroのプロダクションオペレーションマネージャを務めるJeff Smith氏が、11月にニュージーランドのウェリントンで開催されるDevOpsDays NZで、“Moving from Ops to DevOps: Centro's Journey to the Promiseland”と題した基調講演を行う。氏は7月のDevOpsDays Indianapolisでも、専門家によるサイロが同じ課題を異なる動機付けのレンズで検討することにより、企業内で起きる可能性のある不整合状態について講演している。
InfoQは氏に、Centroでの経緯と、2016年のDevOpsDays Minneapolisで氏が講演したGrubhubでのDevOps転向との比較について話を聞いた。
InfoQ: 7月のDevOps Indianapolisでは、企業のさまざまな部署が同じ問題をバイアスの異なる“レンズ”で見ることで発生し得る不整合について講演していましたが、これについてもう少し詳しく説明してください。
Jeff Smith: 分かりました。私たちが実際には問題を同じ視点から見ていない、というのがこの問題です。この話は、大勢の盲人と象に関するインドの寓話を思い出させます。象に出会ったことのない盲人のグループが象を感じて、それを別の盲人のグループに説明するのですが、それぞれが象の違う部分に触っているため、観点が必ずしも重なり合わない、というものです。企業にも同じ問題があります。私たちの目標やインセンティブに大きなずれがあり、結果として無駄な作業や無駄な努力が発生するのです。私たちひとりひとりが作業をしている状況を確立すれば、もっと効率的に目標に到達できるようになります。私の目標が可能な限り堅牢なインフラストラクチャを構築することで、あなたの目標がコストを抑えることであれば、コミュニケーションを取らなければ行き詰まることになるでしょう。対話を通じることで、目標を両方とも達成するか、あるいは少なくとも、リーダシップに矛盾を報告して、どちらがより重要かを戦略的に決定することが可能になります。
InfoQ: このような不整合を、Centroではどのように扱ったのでしょう？
Smith: ほとんどの企業と同じように、争いは絶えません。重要なのは、解決すべき問題に関する状況を常に、そう、常に尋ねることです。もうひとつは、誰かが提案したソリューションにフィードバックするだけでなく、問題を適確かつ確実に把握することです。これはXY問題と呼ばれるものです。実際の問題に対して提案したソリューションへのフィードバックを、誰かがあなたに求めているのならば、結果的に基準以下のソリューションになるでしょう。
一例として、ほとんどの人がおそらくは馴染みのあるものが、システムへのプロダクションアクセスを要求する人の話です。実際のところ、彼らにプロダクションアクセスは必要なく、タスクXが実行できればよいのですが、彼らが思い付いた解決策というのが、ボックスにSSH接続してコマンドを実行する、というものだったのです。しかし、これを“他の人々を巻き込まずに、このスクリプトをプロダクションで実行する必要がある”と言い換えれば、可能性の幅は広くなります。自動化して、Jenkinsのジョブにすることも可能かも知れませんし、定期的に実行するようにスケジュールできるかも知れません。プロダクションアクセスを許可するだけでも問題は解決するかも知れませんが、他チームに対して監査上の問題を発生させることになります。
InfoQ: DevOps NZでの講演では、CentroでのOpsからDevOpsへの転換を取り上げていましたが、OpsとDevOpsというのは、あなたにとってどのような意味なのでしょうか？
Smith: OPSは基本的に、私のチームが行っている職務です。ビジネスオペレーションの技術バージョンと考えてもよいでしょう。オペレーションでは、私たちのコードを顧客に届けるプロセスを管理しようとしています。プロダクションシステムはその一部ですが、その一部分であるプリプロダクション(pre-production)システムも多数あります。私の考えでは、それらがすべてOPSの対象なのです。これにはビルドサーバやテスト環境、コードリポジトリ管理といったものが含まれます。DevOpsは、それを行なうためのアプローチなのです。DevOpsはチームではなく、サイロでもありません。DevとOpsがコラボレーションするための方法なのです。このコラボレーションは一般的に、ある種の文化的な変革を伴います。OPSは開発者に対して、環境に関するより多くのコントロール権とともに、可視性を提供しなければなりません。開発側は、自分たちのコードがプロダクションに入ったならば、その管理と運用において、これまで以上に大きな役割を果たすことが求められます。“OPSのみがプロダクションに触れる”、“自分のラップトップを離れたら開発は終わる”という世界は、終わりを遂げたのです。より緊密な関係で作業をする方法が必要であって、それがDevOpsなのだと私は思います。
InfoQ: 転換前のCentro自体の状態や状況は、転換にどのような影響を与えたのでしょうか？
Smith: Centroは当初、そもそもDevOpsというのは何を意味しているのか、という点で苦労していました。私が最初にこの役職の面接を受けた時には、肩書きが“DevOpsマネージャ”となっていました。この名称自体は、この転換をどのように管理するかという、当社の中核的な課題を垣間見せるものでした。私が職に就いた頃、社内にはOPSの鉄則とでも言うべきポリシがたくさんありました。 しかし、社内には数人の主要人物がいて、それぞれが別の作業スタイルを使用しながら、より多くのオーナシップを求めていました。特にひとりの開発者は、自分が担当するシステムに対して驚くほど多くのメトリクスを所有していました。彼は、自分が担当していたシステムで何が起こっていたのかを知ることに、強い関心を持っていたのです。そういった人は、どの企業にも数人います。重要なのは、彼らを見つけ出して解放することです！チームが直面している問題と解決策について、彼らのインプットを求めましょう。可能な協力者をすべて見つけ出して、彼らを利用するのです。
InfoQ: 今回の変革の中で、Centroとそのチームが克服しなければならなかった課題は、どのようなものだったのでしょう？
Smith: 残された最大の課題は、作成されてプロダクションにデプロイされるコードの所有に関する考え方を浸透させることです。私たちはモノリスを運用しているので、同じコードベースにコミットする開発者はかなりの数になります。これが関係者全員に対してある種の責任の分散の役割を果たして、傍観者効果(bystander effect)を生み出す可能性があるのです。我々の変更が問題を発生させたと、どうして分かるのか？他の変更かも知れないじゃないか！所有者意識を浸透させるために私たちが見つけた最良の方法は、問題を特定の人たちに確実にアサインすることです。共通の問題にしておくと、結果として、他の誰かがその問題を見ているだろうと全員が思うようになります。しかし、特定の人物が問題を所有することになれば、その問題を解決するか、あるいは問題の本当の所在を示す証拠を作った上で、そちらに問題を転送することになるのです。重要なのは、問題の所有者を明確化することです。
InfoQ: DevOpsに転向してから、Centroの企業文化はどのように変わりましたか？
Smith: 実行されていることの理由を、皆が知りたがるようになりました。それがおそらく、私の目にした最大の変化です。“なぜ？”を問う行動は、単に要求を自分のプレートから外して次の作業に移るということを越えた、新たなレベルのエンゲージメントが存在することを示しています。何かを理解していない場合は、それを理解するために適切な質問を徹底的にします。フェールしたジョブ実行に関する簡単な質問が、データベース内でのログ先行書き込み(Write Ahead Log)レプリケーションの動作に関する詳細な議論に発展するかも知れません。人はもともと、より多くを学びたいと思うものなのです！
InfoQ: 実践ベースのサイロに戻ってしまわないためには、どのような対策を取っていますか？
Smith: 問題にアプローチする方法についての規律です。何かがうまくいかない時に、新たな承認層や別の監視層を追加するというのはお決まりの対応ですが、それでは現在の状況につながった実際の問題は何も解決しません。事後分析も好んで行なわれる行動ですが、出来事の順序よりも、むしろ問題の人間的側面が重視されています。何か特別な決定をした時、彼らは何を考えていたのか？なぜそれが合理的な選択のように思えたのか？古いやり方に陥っていないことを確認するために、その問題から何を学ぶことができるのか？うまくいかないことについては、通常の懲罰的な文化の中で失敗について語るよりも、はるかに深い意味において語ることが必要なのです。
InfoQ: CentroでのDevOps文化導入の過程において、技術系以外のパートナからはどのような反応がありましたか？
Smith: 技術系以外のリソースとは、正直なところ、文化的な違いを見るレベルでは接していませんが、能力的な変化は見られます。特定の機能をテストするミニ環境を自身で所有できれば、非常に強力です。それが数日ではなく数分で手に入るのならば、変革のタイプと、私たちが目指しているスピードを証明するものになります。
InfoQ: 以前にもDevOps Minneapolisで、GrubhubでのDevOps転向について講演していますが、この2社での経験を比較してどのように思いますか？
Smith: Grubhubはテクノロジを出所とする企業なので、内容はかなり違います。Grubhubは常にテクノロジ企業でしたが、Centroはどちらかというと企業内企業の様相を持っていました。Centroはサービス企業として古くからありましたが、SAAS製品を新たに持ったことで、創業時からハイテク企業であった企業とは違う部分で成長の苦労を経験しています。考え方が違いますし、見解は以前の業態から引き継いでいるので、Gruhubのそれよりずっと強固なものです。どちらが優れているとは一概に言えませんが、それぞれに異なる課題のあることは間違いありません。もうひとつ大きく違うのは、技術部門の規模です。Grubhubでは、すべてのストリームチームにOPSエンジニアがいて、チームの一員としてスタンドアップやIPMセッションに参加していました。Centroのチームはもっと小規模で、そこまでのリソースもありませんから、プル方式とプッシュ方式の両方でもっと専門知識を提供する手段を考えなくてはなりません。皆が私たちのところへ意見を聞きに来なくてはならないので、その行動を奨励するための方法を常に探す必要があります。結局は関係性の構築と、抵抗なく質問ができるような文化を作り上げることが重要になっています。
InfoQ: 両社に共通した教訓で、特に際立っていたものはありますか？
Smith: 人はいつでも、よりよいやり方を探しているものです。変革の達成を妨げるのは願望ではなく、恐れです。失敗への恐れ、過ちへの恐れ、変化への恐れです。恐れを無視するのは、ソリューションの勝利ではありません。恐れは他の感情と同じで、管理し対処する前にそれを認め、事実として受け入れる必要があります。
InfoQ: そのような恐れの存在に対処するためには、どのようなアプローチが効果を発揮するのでしょうか？
Smith: リーダとしてまず最初にできることは、弱さを見せることです。間違いを認めることを恐れてはいけません。チームや周りは、あなたを例として見習うからです。知らないことは知らないと認めて、あなたが答を持っていないこと、知識欲を持つことは許されるのみでなく、奨励されるものであることを示してください！あなたの環境で他の人たちが行っていることに興味を持って、彼らがあなたに何かを教える機会を与えてください。恐れは信頼の欠如に根ざしているので、恐れを払拭する前に、まず信頼を構築することが必要なのです。
最終的には、インシデントや機能停止といったことが起こります。その場合には、誰が、いつ、何をしたかということではなく、もっと深い、問題の根本的な原因を調べてください。日中にFrankがノードを再起動した、ということだけではありません。なぜFrankはノードを再起動したのか？どのようなシグナルが彼の意思決定につながったのか？これが誤った判断であるとFrankに知らせるためには、どのようなシグナルが欠けていたのか？次に同じ状況が起きた時、人的エラー発生の要因となったシステムのすべての部分に対処するために、トレーニングや情報拡散を通じてこれらのことを明らかにするにはどうすればよいのか？問題発生につながった人だけでなく、すべての小さな要素を告発するという、このような意欲を示すことによって、オープンで誠実な環境を作り出すことができます。
最後に重要なことは、正しい失敗の方法と誤った失敗の方法がある、ということです。新たにデプロイしたコードに不安定な徴候がある場合には、別のデプロイにロールバックする必要があります。これは失敗のひとつの方法ですが、よりよい方法は、コードに機能フラグを用意しておくことです。デプロイをせずに、コンフィギュレーションを通じてフラグのオンとオフができれば、企業として望ましい失敗の方法になります。その時は祝いましょう！コードをデプロイし、テレメトリを監視し、問題を発見して機能をオフする開発者がいれば、それもまた勝利です。失敗を排除することはできませんが、つまらない失敗は回避できます。
InfoQ: Centroが採用したDevOpsモデルを最もよく表現しているのは、どのDevOpsトポロジパターンですか？
Smith: 現在はType 1 DevOps組織で、タイプ2とタイプ3のハイブリッドを目標にしています。OPSチームはインフラストラクチャ・アズ・ア・サービス的なモデルで開発者にプラットフォームを提供するのみで、スプリントチームは“コードの作者が運用の責任を持つ(you build it, you run it)”というモードに移行したいと思っています。それにはいくつかのハードルがあります。
- OPSチームがサービスを自動化された方法で確実に提供できるようにするには、アプリケーションの持つ典型的なパターンを、インフラストラクチャの観点から体系化する位置にまで到達することが必要です。設計が具体的になり過ぎると、新たなサービスを採用しようとした時に、作成したインフラストラクチャテンプレートが共用できなくなります。
- 運用の観点に対する開発者の理解を、引き続きレベルアップする必要があります。技術的な知識よりも、回復性や耐障害性の観点から考えることや、アプリケーションのクリティカルパスを重視することの方が重要です。Amazonのホームページにアクセスすると、独立したサービスが数多く関係しています。しかし、そのページの中で実際に必要なのは、検索とショッピングカート機能だけです。これら中心的な機能が提供できない状態が発生した場合、他のすべては省略されるかも知れません。開発者がこのような考え方を常に持つことは、運用の観点で考えるための機会になります。
Smith氏の基調講演は11月5日と6日、ニュージーランドのウェリントンで行われるDevOpsDays NZで聞くことができる。
この記事を評価
- 編集者評
- 編集長アクション