DevOpsの本質は、組織の壁を越えた改善活動である
西野氏は2年前に日本CAに入社する以前、国内SIerで16年間、自治体向けなどのシステム開発の現場にいた。また運用にも興味がありITIL®を勉強し、現職は運用のコンサルタントだ。その西野氏がビジネスのためのITのゴールは何かと考えたとき、答えはやはり「ビジネス価値を向上させるIT」となる。このゴールは、開発マネジメントと運用マネジメント共通だが、達成に向けた考え方や行動には、相反する要素も多い。
開発のマネジメントには、ビジネスのスピードに追従した開発と同時に、コスト抑制が求められている。それでいて品質は高くなければならない。開発の現場では、まずプロセス面ではデザインレビュー、インスペクション、ウォークスルーなどが関心事となる。テクノロジーはアプリケーションフレームワーク、開発言語、テストツールの選択などが気になる。
一方、運用部門のマネージャーの関心事はやはり、安定稼働、信頼性、高可用性、高セキュリティだ。運用の現場が考えていることは、開発の現場とはまったく違う。プロセス面では、ベストプラクティスを集めたITILのようなものをできるだけ取り入れて、自分たちも改善していこうとしている。テクノロジー面ではインフラの自動化、仮想化、ワークフローツール導入などを考えている。西野氏は「開発と運用では、末端に行けば行くほど違うことを考えている」と指摘する。
開発と運用で、異なる指向のマネジメントが現場に要求すると、それぞれが違った欲求を持つ。例えば開発は実用性を重視する。一方、運用は手続きに準拠する欲求がある。従来は、両者の欲求に違いがあっても、何とかなってきた。しかし今、ITには俊敏さへの要求が増える一方、投資は伸びていない。西野氏は「開発と運用の間にある壁をなくし、一丸となって進めるようにする。それがDevOpsムーブメントの原点」と語る。
ではDevOpsの定義は何か。西野氏は、初めてこの言葉を聞いたとき、多くの人がやるようにネット上で検索した。ところが結果を見ると、それぞれ微妙に違う。そこで西野氏は「明確な定義はない」という結論に達したという。
ただ、共通して使われている言葉があることも分かった。それらを拾い上げるとDevOpsは「開発と運用のコラボレーション、コミュニケーションを統合する方法」となる。
4つの視点でDevOpsを捉え、課題と解決策を考える
さらに「DevOpsを実行する」と動詞をつけた場合、どうなるか。そこで西野氏が考えたのは「DevOpsというのは、いわゆる改善活動なのではないか」ということだ。従来の活動と違うのは、組織の壁を越えて行うことがポイントとなっている点だ。
では改善活動と捉えるのであれば、何が重要なのか。西野氏はITILを参考に以下の3つのPを挙げる。
- People（人・組織）
- Process（プロセス）
- Product（ツール）
一般にDevOpsというと、ツールに関心が集まりがちだが、西野氏は「ツールは重要な要素だが、それだけに着目すべきではない。3つの要素をバランス良く考えていくべき」と語る。
次にDevOpsをプラン、開発、運用のサイクルで考えていくと、リリースされたアプリケーションが不具合を起こし、開発に戻される逆進現象が生じることがある。これを西野氏は“ネガティブ・フィードバック”と呼んでいる。その負の部分も含めて全体を見た上で、日本CAではDevOpsを4つの視点で捉えている。
- Service Assurance：死活監視などの運用監視。
- Application Delivery：アプリケーションの設計、製造、テスト、リリース
- Service＆Portfolio Management：情報共有
- Secure：セキュリティ
課題
では次に、開発側と運用側の課題を見ていく。
Service Assurance
例えば本番環境で不具合があった場合、原因がすぐに特定できないと、開発側と運用側に不信感が生じる可能性がある。問題が生じているのはアプリではなく、インフラの可能性があるからだ。どうやらアプリに問題があると分かったら、今度は不具合の再現に時間がかかる。そうすると早く修正してほしい運用側に不満がたまる。
Application Delivery
アプリケーションがリリースされる際、開発側はすぐにでも実行して欲しいが、運用側は決まっているスケジュール通りにやりたい。お互いの時間軸が違う。またリリース前のテストでは、開発側のテスト環境と本番環境に違いがあれば、信頼性には限界がある。
Service＆Portfolio Management
開発側からの本番環境の設定情報などの問い合わせに対し、何度も同じような質問を受ける運用側は不満に思っている。
Secure
開発側は、本番環境にログオンして調べたい。しかし本番環境へのアクセス制限が多すぎ、許されない。
解決策
西野氏は、これらの両者にうずまく不満を解消するため、以下の解決策を提案した。
Service Assurance
開発と運用では、使っている環境もツールも違う。本番環境では、モニタリングで障害を見つけることはできる。その後、本番環境上のツールで原因を特定できれば、開発側は原因追及のため再現する必要がなくなる。
Application Delivery
まずリリースを無人化することで、時間軸の違いを解消できる。テストでは、仮想化環境で開発側の制約を解消する。
Service＆Portfolio Management
構成管理データベース（CMDB）などで情報共有していく。
Secure
本番環境のアクセスに制約が多いのであれば、自動的に特権IDを貸し出すような仕組みを取り入れる。同時にrootで入っても、作業者が特定できる仕組みも必要になる。
サービス仮想化により、テスト環境の制約を解消する
以上の4視点の解決策の中から、西野氏はService AssuranceとApplication Deliveryについて、より掘り下げて語った。
まずService Assuranceでの本番環境における不具合原因の特定では、例えばCA Application Performance Managementというツールを使えば、本番環境でアプリケーションの性能の劣化、不具合を見つけることができる。その後、原因がアプリ、インフラ、ネットワークにあるのかも出す。そこでアプリに不具合があると分かれば、「どこのメソッドがディレイしている」というレベルまで見える。
Application Deliveryにおいて、開発側のテスト環境における制約にはいろいろある。大きいのはアプリケーションの連携先に関する部分だ。仕様書などを元にシナリオを作成してテストするのだが、現実問題として難しさがある。結果、テストできなかった部分で、不具合が発生する。
そこで有用となるのが、連携先サービスの“ふるまい”仮想化する“サービス仮想化”という新しいテクノロジーだ。ふるまいとは、仮想化した連携先にリクエストを飛ばした際に帰ってくるレスポンスのことで、ポイントは応答時間も再現されている点だ。
西野氏は「テストをする上で、興味があるのは連携先のハードウェア、ミドルウェア、データベースそのものではなく、相手のふるまい」と指摘する。CAはそこに着目し、CA LISAという製品を2012年10月にリリースした。導入した米国の銀行では、リリースしたアプリケーションに100万トランザクション中18,000の不具合があったのが、200にまで減少している。
では連携先とのインターフェースの仮想化は、どうやるのか。方法論は2つあり、1つは連携先システムとの間の通信をレコーディングする。リクエストに対する応答を学習し、ふるまいを仮想化する。ただこの方法の場合、トラフィックがないと仮想化できない。
そこで、連携先がまだ存在しない場合などでは、スクラッチでクイックに仮想サービスを生成することもできるようになっている。例えばWebサービスの場合、WSDLさえあれば、それを読み込んで実際に動く仮想サービスを5分程度で作ることができる。
最後に西野氏は「サービス仮想化により、従来のテストにあった制約が大幅に解消される。その結果ネガティブ・フィードバックが減り、生産性も向上する。ぜひ4つの視点からDevOps、改善活動を行ってほしい」と述べ、セッションを閉じた。
