DevOps時代におけるクオリティ・エンジニアの重要性 (前編)

はじめに

お久しぶりです。@numehaです。前回の投稿から約半年間が経過しました。AKB48のあっちゃんさよならライブ生中継を見ながら書いております。
「DevOps時代」なんて目を引くタイトルにしてみたものの、ただの思いつきの投稿です。はい。
とあるメーカで働いている私の体験談や思いを一部フィクションを交えてお届けしたいと思います。何かフィードバックいただけるとこれからの活動の参考になります。よろしくお願いします。

DevOpsって

DevOpsはムーブメントだ!なんて言われていますね。このスライドの説明が一番わかりやすいですね。

そうそう。わかるわかる。。。。
ん。いや、ちょっと待てよ。私は未熟者なのでまだピンときていないのですが、何か違和感がありますね。

開発と運用の垣根がなくなるのだけど責任は異なるの?お互いのことをわかった上で取り組もうということなのだろうけど、そもそもこれ系の話は開発と運用だけに限った話ではないですよね。多少の壁がありながらもうまくお互いのことを理解するのはある意味当たり前の話でみんな苦しんでいる話だと思います。

f:id:numeha:20120823143512j:plain

歩み寄りもしないで一方的に否定から入るなんてもってのほかですね。

そんなこんなで最近もやもや考えながら日々仕事をしているわけですが、自分の中の勝手な定義としては、

何事もDevOpsな態度で取り組め!

これならピンとくるんだな。
相手を責めない、押しつけない、信頼しあう。相手がいてこその自分なのだから。

クオリティ・エンジニアって

一般的にはテスト・エンジニア?ということが多いのでしょうか。呼び方はどうでもよいのですが、あるソフトウェアの品質を最優先に考えて行動しているエンジニアのことです。
そんなのDeveloperであれば品質のこと考えてやってるよ、という声が聞こえてきそうですね。


「最優先に考える」

というところが重要だと私は考えています。


Developerであったら、何かを設計する、開発するということに注力することでしょう。今であればテストが重要だというDeveloperは多いと思いますが、「品質を最優先に考える」ことはかなり難しいでしょう。
また、運用のことも理解して開発をすることが求められていますが、それは意識だけではどうにもならない能力を要することだと思います。
(最優先に考えなくてもソフトウェア開発に重要なことを全て均等に完璧に考えられるスーパーマンだらけの組織は除きますがねw)

というわけで、

f:id:numeha:20120823144853j:plain

クオリティ・エンジニアはDeveloper、Operatorと協力して、品質の高いソフトウェアをリリースしてお客様にビジネス価値を届ける。それぞれが注力して取り組んでいるところの穴を埋めるような、そんな役割として活動するメンバーが重要だと感じています。
DevOpsの議論では、品質関係の話が軽薄な印象を受けます。品質の話は、開発と運用と同等またはそれ以上に難しいことだと私は思います。

だって人間だもの

話がそれますが、なんでクオリティ・エンジニアの役割が必要かと思った理由について少し。
私は長い間Developerとして活動してきましたが、いくら自分がたくさんのテストコードを書いても、いけてる設計だと思っても、たくさんのレビューをしても、思わぬバグを踏むことがあります。

そしてそのバグはリリース直前やリリース後に運用してみて発見されることもありました。
Developerにとってこんな悔しいことはありません。そのときは、なんで事前に発見できなかったのか、自分を責めて責めて枕を濡らした日もありました(言い過ぎましたw)。

そこで発見されるバグは例えば単純なマージミスのときもあるし、テストコードの漏れ、運用環境でしか発見されない問題もあり様々です。
また、ソフトウェア自体ではなくそれをデプロイした実行環境の設定ミスにより思わぬトラブルを踏むこともあります。
OperatorもDeveloperと同じことです。人間なのだからミスだって検討不足のことだってあるんです。

そんなこんなで、開発を最優先に考えるDeveloperと、品質・テストを最優先に考えるクオリティ・エンジニア、安定運用を最優先に考えるOperatorを定義して、お互いが協力して活動すればうまくいくのではないかと思ったのがきっかけです。
協力するということが重要で、お互いが相手のことを考えて行動しなくては意味がありません。

クオリティ・エンジニアは、とにかくビジネス(お客様)視点で、リリースするシステムの品質を向上させることが一番の仕事です。Developerの設計指針や仕様に関して検討段階から参加し、意識を合わせる必要があります。Operatorが運用する環境を理解してテストを実行する必要もあります。
こうすることにより、従来からあるすでに出来上がったもののバグ出しテストにはならず、戦略的に早期にテストを行うことができるようになります。
早期にクオリティ・エンジニアとテスト戦略について議論を重ねることで、バグをなるべく作りこまない開発を意識的に行うことができるようになります。

後編では、そんなクオリティ・エンジニアが取り組むいくつかの事例を紹介したいと思います。

DevOps時代におけるクオリティ・エンジニアの重要性 (後編)

DevOps時代におけるクオリティ・エンジニアの重要性 (前編)からの続きになります。
どうも。@numehaです。
後編はクオリティ・エンジニアが取り組む事例をご紹介していきましょう。

継続的デリバリーからみる課題

f:id:numeha:20120823214537j:plain

お客様に継続的にビジネス価値をお届けするために私たちはサイクルタイムを減らす方法をひたすら考え、改善し続けなければなりません。一方で、サイクルタイムを減らすだけでなく、他にも考えなくてはならないこともあります。

それは、

システムを修正しながら品質を適切に維持していくこと

です。

極端な例ではありますが、リリースまでに全てが完璧に自動化されたとしても問題を発見できない仕組みであれば全く意味がありません。
ソースコードを修正するもしくは運用環境の設定を変更したことで何か問題が発生した場合、私たちはいつその問題をどうやって発見できるのかが重要なんです。

そんなわけで、私達クオリティ・エンジニアがDeveloperやOperatorをサポートする3つのことを紹介していきましょう。

クオリティ・エンジニアが取り組む3つの事例

私たちは主に以下の3つのことについて取り組んでいます。

  1. リリース基準を規定する
  2. システムのキャパシティを測定する
  3. 環境をテストして監視する

詳細は以下に記載しますが、前提条件として変更に強いテストでなくてはなりません。内部設計に依存したテストであれば、DeveloperとOperatorとかなり密になって活動しない限り追従することが非常に困難になります。

f:id:numeha:20120823215445j:plain

ですので、私たちは品質の外側である外部品質向上に努めることが最善の策であると考えています。内部品質は全てDeveloperとOperatorにお任せということではありません。一番外側の品質を押さえない限り内部品質の強化をしても効率が悪いという意味です。
DeveloperやOperatorが品質確保に向けて行なっていることがより細かいレベルでできるように。そんなことを期待しながら活動しております。

1. リリース基準を規定する

リリースする基準となるテスト仕様を策定し、お客様に提供するビジネス価値を明確にすることがまずは必要です。言ってみれば、これがシステムの仕様になりえるのです。フィーチャー開発をしている人であれば、一つのフィーチャーに複数の受け入れ基準を設けることは実践していることでしょう。
私たちはこのテストをリリーステストと呼んでいます。受け入れテストと同義です。
特徴的なこととしては以下の2つです。
f:id:numeha:20120823221418j:plain
一つ目はとにかくシステムが運用される本番環境と同等の環境でテストをすることです。
ユニットテストであればむしろ逆で環境に依存しないテストコードでなくてはならないと思いますが、リリーステストは違います。お客様が利用するであろう環境で継続的にテストをすることで、Developerを安心させ自信を持ってもらうことができます。
また、本番環境と同等の環境で継続的にテストをするということはデプロイも継続的にされるということです。例えば、開発した内容が運用環境に影響するような修正だとしたら、自動デプロイスクリプトを変更することになることでしょう。こういうときこそDeveloperとOperatorと連携することで、実際に本番環境にデプロイするときのミスや漏れがなくなるはずです。

f:id:numeha:20120823221425j:plain
二つ目はリリーステストファーストです。
前編でも少し触れましたが、開発当初からこれから開発するものがビジネス(お客様)視点でどういうものになるのかを意識合わせすることが重要です。すでに出来上がったものに対してテストをするのではなく、これから作るものに対してテストを一緒に作成するのです。
テストと開発は同時進行し、開発途中でも上述した本番環境と同等の環境でテストを行い、途中経過を全てのメンバーが把握することができます。
クオリティ・エンジニアはDeveloperが開発しやすい環境を整備し、自信がもてるテストコードを書き、Operatorが安心して運用できる仕組みや、デプロイテスト等を継続的に行うことでサポートできるのです。

2. キャパシティを把握する

キャパシティは定義するのが難しい非機能要件と言われるものです。
なぜ難しいかというと、実際にお客さんがいない状態でどのくらいのユーザに利用されるかもわからないのに「100万ユーザ分処理できること」みたいな適当な非機能要件を定義しても意味がないからです。実際に私達も非機能要件はありません。
一般的に機能要件が重視され非機能要件は軽視される傾向にあると思います。
とはいえ、自分たちが開発しているキャパシティを何も把握していないのは健全な状態ではありません。
ですので、まずは計測して自分たちのシステムの特性を把握しましょうというのが一番の目的です。
私たちは、Jenkinsのダッシュボードから簡単に提供しているサービスのキャパシティを把握することができるようにしています。
具体的にはPlot Pluginを利用しています。

f:id:numeha:20120827141508j:plain

こちらもリリーステストと同様に本番環境と同等の環境で継続的にテストを行なっています。継続的に行う理由は、サービスの変更や環境の変更によるキャパシティの変化の傾向を把握するためです。
ですので、今の実力値を把握することができます。あとはここから具体的な非機能要件に落としこんでいくのもよし、あえて非機能要件に落とし込まず、想定外であるシステム特性について優先順位をつけて対応してもよし、ですね。

リリーステストもそうなのですが、このテストで全てがわかるわけではありません。あくまでお客さんが利用する一番外側の品質を向上させるために行なっています。例えば、キャパシティテストの例で言えば、ここで測定された結果はサービスに依存するものなのか環境に依存するものなのかこれだけでは把握することができません。ただし、このテストだけで十分なこともあるしもっと細かくテストをしないといけないものもあるでしょう。

私の考えとしては、細かくキャパシティテストをする戦略をとるよりは大雑把な現状値を把握し、Developerはサービスの改善の準備を行い、Operatorは環境設定の最適化の準備やサーバ増設などの計画値として利用する。それくらいがいいのではないでしょうか。

3. 環境をテストして監視する

さて、上述してきたような継続的なテストとはシステムの監視をしていることと同じです。
f:id:numeha:20120825235150j:plain

私たちはリリース前に行ったテストをオールグリーンにすることだけで果たして十分なのでしょうか。
運用している中で問題が起きることがありますよね。原因は様々かもしれませんが、その異常な状態のときにオールグリーンであったテストを通そうとしてもレッドになるはずです。
ということは、リリース後の運用している状態のときでも継続的にテストをしてシステムを監視してはじめてシステムの品質が保たれるってもんです。

監視というと、データベース、CPU、HDD、メモリ、ネットワークトラフィック、などなど様々なことをやらなくてはいけないと思います。
ただ、監視したものが実際にお客様に影響をおよぼすものなのかそうでないのかを瞬時に把握することは難しいです。

というわけで、これもまた一番外側からの監視になるのですが、上述したリリーステスト、キャパシティテストを本番環境で実行することでお客様に影響を及ぼしているのかそうでないのかを切り分けることができます。

ただ、このようなテストは時間がかかることがあります。監視目的のテストに数時間もかかっては全く意味がありません。
私たちはお客様に提供しているシステムが正常に動作しているのかを少なくとも数分で検知できるように最適化をしてテストを行なっています。このテストを継続的に行うことでお客様に影響を及ぼしている状態なのか安定しているのかを監視することができるのです。

非常に単純な仕組みですが、意外とこれが役に立ちます。お客様が利用する動作を継続的にやっていることになりますから確実性がありますし、複数の動作環境がある場合でも瞬時にサービス群が適切に動いていることを確認することが可能です。

まとめ

前編、後編とまとまりのない文書でしたが、最後まで読んでいただきありがとうございました。
本文の中で、「協力」「連携」と記載することが多かったですが、簡単なようで非常に難しいことです。自分のことだけやるのは簡単です。相手のことを考えて行動するのは一人一人の意識だけでなく、リーダーやマネジャーの理解も必要になります。組織としてどのように行動すれば最適化させることができるのかを皆で議論していくのが良いと思っています。

「個人ではなくチームとして活動する」

自分が最近とても意識していることです。
皆さんのこれからの活動のちょっとした参考になることを祈って。また半年後にw

参考