• 再利用のマインドセット　エンタープライズ・アーキテクチャの労力が将来に実を結ぶために重要なことは、IT部門、そして組織全体に再利用のマインドセットを定着させることだ。再利用のマインドセットが定着したデリバリー・チームは、既存のデータソース、サービス、コンポーネント、フレームワーク、テンプレート、および他の多くの資産を活用するように努めている。このマインドセットは、エンタープライズ・アーキテクト（理想的には、アーキテクチャ・オーナーとしてITデリバリー・チームのアクティブメンバーであることが望ましい）による教育、コーチングとメンタリングを通して植え付けられる。また、ITデリバリー・チームが使うべき、あるいは使用すべきではない技術を示す技術ロードマップによって可能となる。そしてもちろん、発見しやすく理解しやすく、適用して真の価値を提供できる高品質なアセットの存在が再利用を可能にする。
• 技術的負債のマインドセット　エンタープライズ・アーキテクチャの取り組みでは、デリバリーチームが技術的負債を発見した時にその負債を返済するよう、彼らを動機付けるアプローチを推進すべきだ。さらに重要なのは、最初の段階でそのような負債をかぶらないようにすることだ。多くの技術的負債戦略が、DADフレームワークに埋め込まれているが、技術的負債のマインドセットなしでは、無駄に終わることが珍しく無い。エンタープライズアーキテクト（しばしば、デリバリー・チームのアーキテクチャ・オーナーとして機能する）は、技術的負債に関連する問題を中心に、開発者をコーチし、メンターとしての役割を果たす必要がある。同様に、この技術的負債にかかわってコラボレートする、よりシニアなマネージャーや利害関係者を教育するために役立つはずだ。技術的負債を回避し取り除くためには投資が必要であり、普通IT投資の判断は彼らの手にあるからだ。
• 開発のガイドライン　エンタープライズ・アーキテクチャの重要な側面は、ITデリバリー・チーム全体で共通の懸念に対処するためのガイドラインの開発である。組織は、セキュリティガイドライン、接続のガイドライン、コーディング標準、および他の多くを開発することがある。共通の開発ガイドラインに準ずることで、ITデリバリーチームはより一貫性のあるソリューションを構築し、それは転じて本番稼働時により簡単に操作できサポートできるソリューションとなり、DevOps戦略をサポートする。共通の開発ガイドラインの潜在的な欠点は、開発者がそれらによって制約を感じるかもしれないということだ。この問題への対抗策は、ガイドラインはデリバリーチームとのコラボレーションを通して開発され進化されるべきであり、上から課せられるべきではない。
• 技術ロードマップ　エンタープライズ・アーキテクチャでは、技術ロードマップの定義、サポート、そしてそれを進化させるという活動が含まれ、そのロードマップが組織の他の活動（同様に重要なビジネスのロードマップはプロダクトマネージメントの範疇）をガイドする。このロードマップは、本番環境に共通の一貫した技術的インフラストラクチャーを構築することを助ける。この技術インフラが共通のDevOpsプラクティス―継続的デプロイ、自動化されたエンドトゥエンドのリグレッションテスト環境、以前のブログでも議論した運用のモニタリング―を実現するのだ。

1. オーナーシップ　あなたの組織は自身のインフラストラクチャを所有し運営するのか、あるいは外部の専門家にその一部または全部をアウトソースするのだろうか？アウトソーシングオプションには、他の組織（HPやIBMなど）が外部の組織（AmazonやGoogleのような）が提供するクラウド技術を使ってあなたの会社のデータセンターを運用するという従来のアプローチも含まれる。独自のインフラを所有することの利点は、かなりの部分をコントロールできることだ。これはITソリューションのセキュリティと整合性を保証しなければならないときに非常に重要だ。アウトソーシングは、潜在的に規模の経済からITインフラストラクチャとコスト削減を管理する上でより大きな柔軟性をもたらす。しかし、アウトソーシングは、より洗練されたガバナンスを必要とし、前述した従来のアプローチの場合には、アウトソーサーがあなたの要求にタイムリーに応答できない場合、潜在的なボトルネックになる。
2. 仮想化　特定のソリューションのニーズを満たすために構築された、あるいは可鍛性(※訳注)と進化のしやすさを実現するためにソフトウェア化（softwarization）されたITインフラストラクチャの構成要素があるか？ソフトウェア化―ソフトウェア定義インフラストラクチャ（SDI）として知られている―では、ITインフラストラクチャの要素が完全に仮想化される。ソフトウェア化は、ソフトウェア定義データセンター（SDDC）、ソフトウェア定義（SDS）、およびソフトウェア定義ネットワーク（SDN）を包含したITインフラストラクチャモデルを含む。ソフトウェア化は、通常、ファイアウォールの両側で、クラウドベースのテクノロジを使って実装される。さらに進んだ仮想化のソリューションでは、ITインフラストラクチャの柔軟性とプログラマビリティを高めており、それによってリソースの最適化を可能にする。その一方で、仮想化がもたらすより大きな柔軟性は、あなたのテスト作業の複雑さを増加させ、運用での課題をシミュレーションすることをより難しくする。
   ※訳注　”可鍛性”：原文では”malleable”。外的圧力を受けても破壊されることなく変形できる能力。ここでは、ビジネス等の外部環境の変化に呼応して変化できる柔軟性という意味。

 

Tweet

Pocket

• データと情報に関するのガイドライン　開発と、データや情報ソースの応用利用との間により高度な一貫性を確保するための直接的な方法は、チームが利用する共通のガイダンスを策定することだ。このガイダンスには標準ポリシーとガイドラインの両方が含まれる。利用者間のコラボレーションとオープンなやり方で定義され、サポートされ、そして時を経て進化し続ける。
• 質の高いデータソース　ファイル、データベース、およびデータフィードなど、本番のデータソースは、簡単に利用出来る高品質なアセットであるべきだ。データソースに記録された後、それらのレコードが高品質であることは特に重要で、それがあってこそそれらは簡単に利用され、進化するのだ。残念ながら、多くの組織では、これは空想の域を出ていない。ディシプリンドDevOpsの考え方では、チームはデータソース内の技術的負債を増やすことについては非常に注意を払い、彼らが見つけた技術的負債を返済するための払う労力に投資することがより重要である。
• ITインテリジェンス　ITインテリジェンスは、データウェアハウス（DW）/ビジネスインテリジェンス（BI）ソリューションの作成・サポートとその進化、そしてオペレーションという相対的な活動である。これにより、あなたの会社のIT活動全般の管理とガバナンスをサポートする。ディシプリンドDevOpsの観点から見ると、ITインテリジェンスには、2つの重要な側面がある：デリバリーチームがどのように機能しているかへの洞察を提供する開発インテリジェンスと、運用で何が起きているのかを提示するオペレーショナルインテリジェンスだ。多くの開発プラットフォームが提供する自動化されたチームのダッシュボードは、開発インテリジェンスの単純な形態だが、より洗練された（そして有用な）ものは、様々な開発ツールからの情報を統合し、統合ダッシュボードに表示するものだ。さらに有用なのが異なるデリバリーチームからの情報を集約/統合し提示するポートフォリオマネージメントダッシュボードだ。
  同様に運用チームも各々のソリューション毎に独立したダッシュボードを持っている。各々のソリューションによって生成された情報を結合し
  統合されたダッシュボードに提示したり、ITポートフォリオマネージメントビューで共有すればさらに有用なものとなる。

Tweet

Pocket

• 統合デプロイメント計画作り：開発チームの視点で見ると、デプロイメント計画作りは、組織の運用部門やリリース管理部門のスタッフと常にやり取りすることが求められる：いくつかのケースでは、運用部門の中にリリースエンジニアと呼ばれる専門の渉外担当を置き、彼/彼女を介してやりとりしている場合もある。あなたがディシプリンドDevOpsの考え方を採用するとすぐに理解することになるのは、運用スタッフがすべての開発チームと一緒に作業する必要があるので、デプロイメント計画にはチーム横断のアプローチが必要であろうということだ。運用スタッフにとってはこれはニュースではない。しかし、自分達だけで、サイロ化された環境で作業することに慣れている開発者にとっては驚きとなる（幸運なことに、この戦略は、DADの”Move Closer to a Deployable Release process goal”（未訳）に組み入れられている）。チームがまだこれをやっていない場合は、組織全体のデプロイスケジュールの中でリリース·スロットをめぐる争いを始める必要があるだろう。
• 運用環境に準じた標準的な開発環境とテスト環境：開発チームは、開発、テスト、本番環境との整合性が高まるほど、テストとデプロイがより簡単になることを知っている。複数のチームが作業する環境でこれが暗に意味するのは、最終的には環境の多くの側面が事実上標準化されるだろうということだ。開発者は、別の開発ツールを選択することができるが、インフラの側面ーオペレーティングシステム、アプリケーションサーバー、ミドルウェア、データベース、などーでは、リリースプロセス全体が合理化され、時間をかけて整合性が取られることとなるだろう。
• リリースサービスストリーム：DADフレームワークの主要テナントは、すべてのチームがユニークであるという点だが、それはチームによっては他のチームよりもより多くの助けを必要とするモノがあるということを暗示している。チームの成果物の品質レベルは異なっており、自動化の程度も様々、さらには異なるリリースケーデンスを採用しているといった具合にだ。その結果、これらの状況に対応できるように、リリース管理戦略は、高い柔軟性が求められる。その方法の一つは、ソリューションデリバリーチームに、状況に合わせた異なるサーバーストリームやサービスレベルを提供することだ。たとえば、あなたのチームは基本的なリリース管理サービスストリームを持っているかもしれない。そこでは、リリース管理エンジニアが積極的にデリバリー·チームを支援し、開発成果物を運用環境へのデリバリーし、さらに彼らのプロセスのどこかを自動化する手助けを始めてさえいるかもしれない。
  他方極端な例では、デリバリーチームに対して、継続的デリバリーサービスストリームを提供している可能性もある。その種のストリームでは、テストとデプロイメントプロセスが完全に自動化され、成功にデプロイされるその仕組みに対して高い信頼が寄せられているかもしれない。
  そしてもちろん、これらの両極端の間にいくつかの他のサービスストリームの形態がありうる。このアプローチの利点は、スケジューリングの複雑さのコストが僅かに大きなものになるが、非常に柔軟であることです。
• リリースブラックアウト期間：一部の組織では、よほどのことがない限り、運用環境に新機能をリリースしないと決めた期間を設定している。この種のブラックアウト期間は、多量のビジネストランザクションが発生する時期に設定されることが典型だ。例えば、多くの北米の小売企業は11月半ばから１月上旬のホリデーセールスシーズンのブラックアウト期間を設定することが多い。多くの組織では会計年度の終わり近くに設定する。年度の終わりに必要な処理を終わらせることに集中するためだ。
• 共有されたプラクティス：これは本当にプロセス改善の問題だが、リリース管理に関わる人々は誰でも、効果的なプラクティスをチーム間で共有するために積極的に努力すべきであると指摘する価値がある。学びを共有するというのは、エンタープライズ対応の重要な側面の一つだ。

Tweet

Pocket

• リリースウィンドウ（スロー・ケーデンス）：リリースウィンドウは、一つ以上のチームが運用環境にリリースまでの期間のことだ。リリーススロットは、リリースウィンドウのサブセット（あるいはリリースウィンドウ全体のこともある）であり、この枠の中でチームがソリューションを運用環境へデプロイすることもあるうる。たとえば、本番へのリリースは土曜の夜午前1時から午前5時の間（リリースウィンドウ）に行わなければならず、そのウィンドウの中で4リリースまでは行われうる（リリーススロット）。リーンの用語では、リリーススロットは、チームがデプロイできるカンバンカードに事実上相当する。リリースウィンドウは、システムの利用状況が比較的低調な時間帯に合わせて設定されるのが普通だ。もっとも昨今のグローバル化が進み24×7運用があたりまえの時代には、このウィンドウはあまり意味を持たなくなったが。これにスロー・ケーデンス・アプローチを適用すると、リリースウィンドウは長くなり、1週間に一度など滅多になく、それどころかもっと長くなりさえするだろう。このアプローチの利点は、それがビジネス利害関係者に対しては、一貫したケーデンスでリリースを行い、デリバリー·チームに対しては一貫したリリース目標日をもたらすことだ。スロー・ケーデンス・リリースウィンドウの欠点は、複数チームをサポートする場合にリリース管理プロセスのボトルネックになることだ。各ウィンドウ（期間）中に、あまりに多くのリリーススロットだけがあり、しかもその数は簡単に増やされうるし、これによってチームの意識が将来のリリースウィンドウに向けさせられる。チームが継続的デリバリー戦略に移行し始めると、この問題はさらに悪化してしまう

• リリーストレイン：リリーストレインというアイディアは、ある”列車（トレイン）”に乗っているすべてのチームが、同じリリースケーデンス･･･例えば、四半期に一度か、月に一度、あるいは週に一度･･･で活動するというものだ。この戦略は、一般的により大規模なプログラム（訳注：いわゆるポートフォリオープログラムのプログラム）、またはチーム・オブ・ チームズ（team of teams）と呼ばれる独立したチームの各々が大きな枠組みの中の一部として活動する形態で採用される。リリーストレインが刻むビートを共有することによって、利害関係者に対しては一貫性したリリーススケジュールを提供し、開発チームのためのラリーポイント（＝ 各々が開発していた成果物を集めて統合するタイミング）を提供する。列車のメタファーは、実際に非常にうまく機能する。あなたのチームがリリース日を逃し（リリースできず）、列車に乗り遅れれば、列車はあなたなしで 先に行ってしまい、あなたは次に乗車できる場所で待機する必要がある。依存関係も尊重される。例えば、複数のコンポーネントを一緒に出荷する必要がある場合、それらは同じ列車に乗らなければならない（家族が一緒に旅行するようなものだ）。主な欠点は、開発チームが共通のリリーススケジュールに制約され、それがリーンや継続的デリバリー戦略を難しくすることだ。潜在的な欠点は、スロー・ケイデンス・リリースウィンドウのボトルネック問題に苦しむ可能性があることだ。
• リリースウィンドウ（クイック・ケーデンス）： 継続的デプロイメントをサポートするためには、特に多くのデリバリー·チーム全体を考えた場合、多数のリリーススロットが必要になる。これが暗に示すのは、あなたもこれまで以上に多くのリリースウィンドウを必要とするだろうということだ。クイック・ケーデンス・リリースウィンドウの利点は、スロー・ケーデンス・リリースウィンドウやリリーストレインに起因するボトルネックの影響を受けづらいだろうということだ。
• 継続的リリース・アベイラビリティ：このアプローチでは、デリバリー·チームは、必要なときにいつでも運用環境にリリースすることが許されている。多くの点で、単にリリースウィンドウを24/7にする、これまでのリリースウィンドウ戦略の拡張です。これは本来の意味で、継続的デリバリーをサポートする唯一の戦略です。これを可能にするためには、DevOpsプラクティスのホストがひつようとされる。例えば、完全に自動化されたデプロイメント、完全に自動化されたレグレッション・テスト、フィーチャーのトグル、自己回復コンポーネント、および諸々が必要とされる。

Tweet

Pocket

今回は、DevOpsシリーズの一環として、ソリューションサポート戦略を探索する。ソリューションサポート（ヘルプデスク）戦略にはいくつかあるが、それらは組み合わせることが出来、適切なモノを選択することができる。以下に見ていこう：

• オンライン情報　　　「自己解決（Self Serve）」を促すとても一般的な戦略は、オンラインのアセットを開発・維持することだ。2,3例を挙げるとFAQページ、トレーニングビデオ、ユーザマニュアルといった類いのものだ。　この戦略は、エンドユーザが自分自身をサポートし問題を解決することを促しているが、「よんだつもり症候群」にかかっているにもかかわらず
• オンラインディスカッションフォーラム　　　多くの組織では、エンドユーザー同士がお互いを助けあいながら自社システムの使い方を学習できるように、社内にディスカッションフォーラムを立ち上げている。これは、エンドユーザーが自分で問題を解決するにあたって、効果的に機能する助け合いオプションである。大きな利点は、「パワーユーザー」や場合によっては開発チームのメンバーが、問題と格闘している他のユーザを助けにやってくるだろうという点だ。潜在的な欠点は、問題がタイムリーに解決されない場合に、ディスカッションフォーラムが苦情フォーラムになってしまうリスクがあることだ。
• 非同期サポート　　　非同期サポート戦略では、エンドユーザーがヘルプ要求を提出し、その後少し時間をおいて、誰かが助けに戻ってくる（望むらくは）。非同期サポートを実装する一般的な方法は、標準化されたサポート電子メールまたはサポートリクエストページ/画面を実装することです。多くの組織で、ヘルプを必要とする人々の待ち時間を制限するために、サービスレベルアグリーメント（SLA）を設定しているのがよく見られる。
• 同期サポート　　　　同期サポート戦略では、エンドユーザーがリアルタイムでサポート担当者（アプリケーション開発者の一人であるかもしれない）と接触する。オンラインチャットソフトウェア、ビデオ会議、電話等がよく使われる。同期サポートの重要な利点は、その応答性だ。しかし、同期サポートは、運営が高くつく可能性があり、エンドユーザにとっていらいらの元になり得る。特に、サポートデスク機能がアウトソースされ、所定のスクリプトにただ従うだけのような担当者の場合は、顕著だ。
• サポートアラート　　　　この戦略では、ソリューション自体がエンドユーザに影響を及ぼすような重大な問題ー例えばデータソースやサービス／コンポーネントが稼働しない等ーを検出する。このようなイベントが発生し、ソリューションが迅速に復旧することができない場合、エンドユーザーは問題の通知を受け、場合によっては「助けが必要ですか？」と尋ねられる。yesを選択すると、問題解決に適切なサポート担当者と、その場で直接コンタクトが取られる。これは、ソリューションの自己回復プロセスの一部です。
• 開発者主導のサポート　　　　この戦略は、開発チームが自分達で構築したソリューションサポートを行うというものであり、「DevOps戦略：開発」で紹介したものだ。

DevOpsシリーズの次回は、リリース管理戦略を取り上げる。

オリジナル：DevOps Strategies: Support

http://www.disciplinedagiledelivery.com/devops-strategies-support/

（翻訳　藤井智弘）

Tweet

Pocket

これまで説明してきた一般的なDevOps戦略と開発に焦点を当てたDevOps戦略に加え、DevOpsの運用面をサポートする技術的な戦略を取り上げていこう。

1. ソリューションの監視　　名前が示すように、これは、運用に入った後稼働しているソリューションやアプリケーションを監視するという運用プラクティスである。オペレーティングシステム、アプリケーションサーバー、および通信サービスなどの技術基盤プラットフォームは、ツール（例えば、Microsoft管理コンソール、IBM Tivoli Monitoringの、およびjManageなど）を使って監視する機能を提供していることが珍しくない。しかし、アプリケーション固有の機能を監視するーたとえば特定のタイプのユーザに使われているのは、どのユーザーインターフェイス（UI）機能かといったーためには、組織の監視インフラに準じた監視機能をアプリケーションに組み込む必要がある。開発チームは、このような運用面での要求に注意する必要があるし、そのような機能を組みいれを簡単に行えるフレームワークに利用出来ることが、より望ましい
2. 標準プラットフォーム　　継続的デプロイメントや初期のアーキテクチャ構想のようなソフトウェア開発プラクティスは、運用インフラの一貫性が維持されていてこそ可能になる。一握りの標準のハードウェア構成に展開する方が、ユニークなモノが無数にある環境に展開するよりもはるかに簡単だ。インフラのソフトウェア（オペレーティングシステム、データベース、ミドルウェア等）のバージョンが一貫しているほうが、デプロイはより簡単だ。たとえば、Oracle DBのすべてのインスタンスが11.2.1.3であり、11.2.0.0、12.0.1.0あるいは11.2.1.3がさまざまな場所にインストールされていないという状態だ。また、最初にインフラストラクチャ·ソフトウェアパッケージに一貫性があると、アーキテクチャ上の決定を行うことが非常に容易になる。たとえば、サーバーオペレーティングシステムとしてLinuxを標準化したら、Windows、z/OSおよび他のものは運用しない（さらには、積極的にそれらを引退させる）といったようにだ。
3. デプロイメントをテストする　　ソリューションあるいは運用インフラを構成するコンポーネントをアップデートしたら、デプロイが成功したかを検証する短時間で実行できるテストを実施すべきである。必要とされた正しいバージョンがインストールされたか？そして、それらはすべて適切なサーバーにデプロイされたか？データベース変換が正常に行われたか？必要なら、適切な通知が行われたか？展開プロセス全体が、要求された時間枠内で実行したか？
4. 自動デプロイ　　デプロイは、手動ではなく自動化されるべきである。これはデプロイ作業の一貫性を高め、継続的デプロイの実現をサポートする。自動化に向けての作業の一部を割いて、自己回復と自己テストの両方をサポートするべきだ。
5. サポート環境　　ソリューションをサポートするチームは、たとえそれがデプロイメントチーム自身であったとしても、エンドユーザが体験した問題を再現出来るような環境を必要とするだろう。オプションをいくつか挙げておこう：
   1. 運用環境を利用する　　運用環境をそのまま利用しても十分なケースもあるが、規制制度が関係する場合の多く、特にライフクリティカルや金融等の規制業界では、これは許可されない。
   2. プリプロダクションテストサンドボックス　　サポートチームの中には、運用上の問題をシミュレートするために、プリプロダクションテスト環境を使用できることがある。この利点は、問題を再現しようとしたときに運用環境へリスクを注入しないことだ。デメリットはテスト環境が運用環境とは異なることであり、結果として報告された問題すべてをシミュレート出来ないかもしれないことだ。
   3. サポートサンドボックス　　一部の組織では、サポートスタッフが運用上の問題をシミュレートするために、特定の環境をセットアップしているところがある。この戦略は、プリプロダクションテストサンドボックス同様のトレードオフに加えて、さらに別の環境を所有する追加コストやメンテナンスというトレードオフがある。

このDevOpsシリーズの次のブログ投稿では、ソリューションのサポート戦略を探る。

オリジナル：DevOps Strategies – Operations

https://disciplinedagiledelivery.wordpress.com/2015/02/19/devops-strategies-operations/

(翻訳：藤井 智弘）

Tweet

Pocket

In this image made from KVUE-TV video, smoke billows from a seven-story building after a small private plane crashed into the building in Austin, Texas on Thursday Feb. 18, 2010. (AP Photo/KVUE-TV) MANDATORY CREDIT

今回は、災害対策(Disaster mitigation)という観点での戦略を見ていくことにしよう。

1. 災害対策計画　統制のとれた組織（Disciplined oraganization）は、様々な運用の失敗に対応する計画を決めるだろう。起こりうる災害・失敗の例としては、サーバーのダウン、ネットワーク接続のダウン、電力喪失、ソリューションのデプロイの失敗、インフラ導入の失敗、自然災害ー火災、洪水ー、テロ攻撃その他諸々がある。この計画作業では、潜在的な問題の識別、それらの問題に対処するための戦略の識別、そして、災害の影響を軽減するためのメカニズムをどこに置くことが適切かが検討される。この類いの災害・失敗に対して取り得る戦略には、自己テストと自己復旧を行うソリューションの構築や、運用インフラに冗長性を持たせるといったアプローチがあり、これらは同時に問題発生時に実施するとされ、問題のシミュレートを通して実行可能である対応手順が定められている。
2. スケジュールされた災害シミュレーション　災害に備えたプランが定められているということと、それが実際に機能するか否かを知っておくというのは大事なことだ。統制のとれた組織では、問題発生時の影響軽減戦略が実際にどのように機能するかを確認するために、災害シナリオを実行するだろう。たとえば、停電の緊急時計画では、意図的にデータセンターの一つで停電をシミュレートしてから、リカバリ計画が有効に動作するかどうかをテストする。スタッフが緊急時に迅速かつ適切に行動できるよう、必要な手順を「身体に覚え込ませる」ために、消防訓練と同様に、これらのシミュレーションは、定期的に行われるべきだ。スケジュールされた災害シミュレーションの利点は、利害会関係者に最小限の影響しか与えないだろうという時点で意図的に実行できることだ。欠点として挙げられるのは、少なくとも実行に先立ち人々に知らせることによって、シミュレーションに対して心の準備が出来てしまい、「不意の状態」を作れないことだ。だから実際に緊急事態が起こった場合に人々がさられるであろうストレスを、現実的なレベルでシミュレートすることができない。
3. ランダムな災害シミュレーション　高度に練度が上がった組織では、サーバーやサービス停止をランダムに引き起こすサービスを運用環境内で実装するだろう。この機能の例が、AmazonのWebサービス（AWS）で提供されているカオスモンキー(Chaos Monkey)だが、同様の機能性が多くの組織で実装されている。カオスモンキーは、運用環境にランダムに問題を注入して、それによってIT運用部門がそれらを克服することが出来るか否かを確認することができる。ソリューションが、発生した問題から本当に自動的に復旧できるか、失敗するにしても少なくともオペレータに警告を発することができるかが検証される。

皆さんが予想されるように、真の統制された組織は、以上に挙げた戦略すべてを適用している。

関連投稿：

• DevOps戦略：ディシプリンドDevOpsを定義する
• DevOps戦略：概論

オリジナル：DevOps Strategies – Operational Disaster Strategies

https://disciplinedagiledelivery.wordpress.com/2015/02/17/devopsdisasterstrategies/

(翻訳：藤井 智弘）

Tweet

Pocket

今回の投稿では、開発と運用各々の専門家が共同で作業する際に適用できるチーム編成戦略について見ていこう。小さくはじめてやがて大きな効果へと繋げていこう。

1. 運用への引き継ぎ　　開発チームがソリューションを運用にのせた後は、運用チームがその稼働とサポートの責任を担う。この時点で、開発チームは解散されているか、あるいは別の作業へと移っていくことが珍しくない。2〜3名の開発者をリリース後も必要に応じてメンテナンスアップデートを開発する保守チームとして編成したり、あるいはこの手の作業を既存の保守チームに移管することに責任を持たせるという手もある。この戦略の利点は、開発チームをそのまますべて維持するために、組織がもはや投資する必要がないということだ。その一方で、メンテナンスと機能追加のために長期にわたり必要とされるチームの知識と専門技術を失う危険性がある。これは特に重大な不具合が発生した時に大きな問題となりうる。
2. 保証期間　　この戦略では、ソリューションがリリースされた後あらかじめ定められた期間内であれば重大な不具合に対応することに、開発チームはコミットする。たとえば、開発チームは、製品リリース後の最初の30日間重大度1または重大度2の不具合を無償で修正することを求められるというケースだ。保証期間戦略は、それに伴うリスクを低減するため、（前述の）運用への引き継ぎ戦略と組み合わされることが多い。開発チームが固定価格モデルで契約している場合、あるいはアウトソーシングでは、保証期間戦略は普通に採られている。なぜなら、利害関係者は、支払った価格に見合ったレベルの品質を手にしたことを確認したいからだ。
3. 実稼働のサポート　　エンタープライズ環境では、ほとんどのアプリケーション開発チームは、すでに運用されているサービスの、新しい（次の）リリースに取り組んでいる。彼らは新リリースの開発をするだけにとどまらず、運用中に発見された重大な問題にも対処する責任を併せ持っている。開発チームは、しばしば「レベル３サポート」と呼ばれることがある。それは、彼らが重大な運用上の問題を修正する場合に、関与する第3番目（そして最後の）チームだからだ。このやり方の最も有利な点は、特定のソリューションに起因して発生した運用の緊急事態が、そのソリューションに最も詳しい人達ーつまりそのソリューションを実際に開発した人達によって解決されるということだ。別の利点として挙げられるのは、運用時に発生する様々な事象を開発者に認識させ、まず始めに彼らがソリューションを設計する方法を改善する機会を与えるということだ。潜在的に重大な欠点は、運用での緊急事態を修正する必要が、新しい機能に取り組んでいる開発者の気をそらせるという点だ、
4. 開発者主導による運用　　この戦略は、開発チームを運用サポートチームに転換させ、彼らが開発したソリューションの運用とサポートの責任を持たせるというものだ。これは「あなたが構築し、あなたが走らせる」としばしば呼ばれている。この戦略を採用すると、運用やサポートが容易にできることに、開発チームがソリューションの開発時に焦点を合わせるようになったり、最もそのソリューションに詳しい人達がそれをさらに発展させるということが確実になるという恩恵が得られる。しかし、この戦略を採ると、異なるプラットフォームで稼働するサイロ化されたソリューションを開発するスクラムチームが出来上がるー幸いなことに、DADチームはエンタープライズを常に意識(Enterprise aware)しており、アーキテクチャオーナーの役割をチームに組み込み、チームをガイドすることで、まさにこの類いのアーキテクチャー上の誤りを避けることができる。 もうひとつの一般的な戦略は、あなたのチームに運用経験の豊富な人を引き入れるというものだ。開発者が運用を主導するという戦略は、様々なレベルでサポート品質のリスクを引き起こす。たとえばチームによってサポート品質にばらつきが発生するようなケースだ。　今一度確認しておくが、エンタープライズを常に意識するチームは、共通のガイドラインに従う重要性を理解しているし、自分達のやり方を改善するために、他のチームを助けることを厭わない。

上記の4つの戦略が示すのは、DevOps戦略といえる唯一のものは、開発者主導による運用であるということだ。この運用サポート戦略は、間違いなく正しい方向への第一歩であり、多くの企業で十分に運営されているところが見られる。あなたの組織の事を考えた場合、我々は開発者主導による運用を試してみて、どの程度うまく機能するか実験してみることをお奨めする。その良好な結果に驚かれることだろう。

次回は災害対策戦略を探っていこう。

関連投稿：

• DevOps戦略：ディシプリンドDevOpsを定義する
• DevOps戦略：概論
• DevOps戦略：開発

オリジナル：DevOps Strategies –  Teaming Strategies

URL : https://disciplinedagiledelivery.wordpress.com/2015/02/13/devopsteamingstrategies/

（翻訳：藤井　智弘）

Tweet

Pocket

前回の投稿では一般的な戦略を取り上げたが、それに加えてディシプリンドDevOpsをサポートする共通の開発プラクティスがあるので、以下に見ていこう。

• カナリアテスト カナリアテストは小規模な実験だ。新しい機能を一部のエンドユーザに提供し、その機能が彼らの興味をひくものか否かを判断出来る。見方を変えると、開発チームはこのテストから、機能の（もしあれば）真の潜在的な価値について、洞察を得ることが出来る。
  例えば、あるeコマース企業は、関連する2つの商品を割引価格で購入することができる新しい機能が売上を伸ばすだろうと考えているかもしれない。同時に、これが全体の収益を減少させる可能性を恐れているかもしれない。
  そこで、彼らは、顧客の5％に2週間の間だけこの機能を提供するカナリアテストを実行することにした。売上と収益を追跡し、この新機能へのアクセスを与えられていない顧客と比較するのだ。新機能がカナリアテストを成功裏にパスすれば、その後、より広い範囲のエンドユーザに提供される（何段階のステップを経て最終的にすべてのユーザに展開するというやり方もある）。カナリアテストを、パイロットテストの極端な形態として見做すことが出来る。
• スプリットテスト  また、A / Bテストとして知られているスプリットテストは、2つ以上のオプションが並列で実行され、それらの有効性が比較される実験である。
  例えば、銀行が、現金自動預け払い機（ATM）を使った2つの口座間での資金転送のために、3つの異なる画面設計アプローチを考えたとしよう。エンドレスの会議やフォーカスグループ、あるいはモデリングセッションを行う代わりに、銀行は3つすべてを実装しサービスとして並行して提供する。私がATMを使用する時はアプローチAの画面が現れ、あなたがログインするときにはアプローチBが現れるといった具合だ。
  ATMのソフトウェアには、重要な利用状況を把握するためのメトリクスを収集する機能が組み込まれているので、銀行はどのアプローチが最も効果的か決定することができる。スプリットテストの終了後、もっとも効果が高かったアプローチによる画面が、ATMのすべてのユーザに提供される。
• 自動化された回帰テスト　アジャイルソフトウェア開発者は、”品質感染症”と呼ばれることがあるが、それは彼らが質の高いコードを書くことにフォーカスし、出来るだけ早くから出来るだけ頻繁にテストをしたいという欲求を持っているからだ。その結果、自動化された回帰テストは、アジャイルチームにとって共通のプラクティスとなっている。時にはテスト駆動開発（TDD）とビヘイビア駆動開発（BDD）といったテストファーストのアプローチに拡張されていることもある。リグレッション·テスト·スイート（S）には、機能テスト、パフォーマンステスト、システム統合テスト（SIT）、および受け入れテストと、その他多くのカテゴリーのテストを含む。
  アジャイルチームは普通日に何度も自動化テストスイートを実行し、問題をすぐに解決するので、実践していないチームではなしえないような高いレベルの品質を達成するし、開発者はそれを楽しんでいる。テストによっては、特にロード/ストレステストやパフォーマンステストのように、実行に長い時間がかかるものもあるので、異なるケーデンスで実行するテストの組み合わせをいくつか用意することになるだろう（例えば、ある種のテストはコードがチェックインする度に実行されるが、ある種のテストは1日のうちの決まった時間に実行される。また、あるテストは夕方に一度実行され、あるテストは週末に実行される、といったように）。
  品質に対してこれまで以上にフォーカスするというのは、運用スタッフにとっては良いニュースだ。なぜなら運用スタッフとは、ソリューションは本番サービス稼働前に十分な品質が確保されていなければならないと主張するものだからだ。
• 継続的インテグレーション（CI）　継続的インテグレーション（CI）は、ファイルが構成管理（CM）システムにチェックインされるたびに自動的にプロジェクトをビルドし検証するという原則だ。次の図に見られるように、検証は、自動回帰テスト、さらには、静的または動的なコードおよびスキーマ·分析などの、複数のアプローチで行われる。CIは、コードの不具合に関して迅速なフィードバックを提供することで、開発者が少しずつ繰り返し行われる定常の手順で、安全に高品質のソリューションを開発することを可能にする。
• 継続的デプロイ（CD）　継続的デプロイは、継続的インテグレーションのプラクティスを拡張したものだ。継続的デプロイでは、あるサンドボックスで統合に成功したら、その変更されたコードは次のステージのサンドボックスに自動的に引き渡される（これを、”昇格する”と呼ぶ）。ソースファイルの変更を受けて、そのサンドボックスで実行されているCI機構があなたのソリューションに統合する。
  下図を見るとわかるように、この自動的な昇格は、いかなる変更も人によって検証されなければならないポイントー一般的には開発から運用へと遷移するタイミングまで続く。今や先進的なチームは、本番環境へのデプロイまで自動的に行っている。継続的デプロイによって、開発チームは、新たな機能が識別され運用に供されるまでの時間を短縮させることができる。それは、ビジネスの応答性能を高めることに繋がる。
  しかし、開発チームが未成熟な継続的デプロイを行っていると、本番環境に潜在的に不具合を紛れ込ませることになり、運用上のリスクを増加させることが起こりえる。エンタープライズレベルで継続的デプロイを成功させるためには、すべてのサンドボックスで実行される、効果的な継続的インテグレーション戦略が必要だ。
  ディシプリンドDevOpsの考え方を理解している開発者がソリューションをビルドする際に採用する、運用に親和性の高い共通の機能を以下に挙げてみよう。

• アクセス制御機能　カナリアテストやスプリットテストのような実験的な戦略をサポートするために、ある特定の機能へのユーザアクセスを制限する機能が必須となる。このアプローチは、設定とデプロイが簡単にできなければならない。よく使われる方法としては、XMLベースの構成ファイルを利用するもので、実行時にメモリに読み込まれ、アクセス権限を制御するためのメタデータが記述される。
• モニタリング機能　ディシプリンドDevOpsの考え方を理解している開発者は、計測機能ーログの出力とよりリアルタイムに近いアラートーを彼らのソリューションに組み込む。この目的は、運用に入っているシステムを、（ほぼ）リアルタイムで監視出来るようにすることだ。リューションを運用し続ける責任を担っている人々、問題をデバッグし解決する責任を担っている人々、運用インテリジェンスを利用する人々にとって、この機能は重要だ。
  モニタリング機能を組み込むことで、カナリアテストやスプリットテストの際に、テスト中のフィーチャーや戦略の有効性を判断するために必要なデータを収集することができるようになる。
• フィーチャートグル　フィーチャトグルは、適切な場合に機能をオン/オフできるようにする、便利なソフトウェアスイッチのことだ。よくある使い方は、価値ストリームーエピックあるいはユースケースで記述されるーを提供する一連の機能群を、ユーザの受け入れ準備が整った暁に一斉にオンにするといったものだ。フィーチャーがうまく機能していない（エンドユーザにとって有用性が見いだせなかったり、結果として売上減になったり･･･）とわかった時に、特定のフィーチャーをオフする場合にもよく使われる。
  フィーチャートグルのもう一つの利点は、インクリメントベースで、機能を本番運用にデプロイできることだ。
• セルフテスト　ソリューションをより堅牢で、操作しやすいモノにする1つの戦略は、セルフテストが出来るようにすることだ。基本的な考え方は、本番運用中に適切に稼働するということを検証する基本的なテストを、ソリューションの各コンポーネントに含めるというものだ。例えば、アプリケーションサーバーが、オペレーティングシステムやフレームワークのバージョンが適切かを、スタート時に確認するというような基本的なテストを実行する。サーバー稼働中に、データソースやミドルウェアサービスといった関連する他のコンポーネントが利用可能かどうか定期的にチェックすることもある。問題が発見されたときには最低でもログに記録されるべきだし、さらには人による介入が必要なケースにはアラートが挙がったほうがよい。もっと言えば、ソリューション自体が問題からの回復を試みるとなお良い。
• 自己回復　システムに問題が発生した際に、自動的にそこから回復し以前と同様にサービスを継続させられるのがベストだ。例えば、システムがデータソースが使えなくなったと発見した場合に、データサービスの再起動を試みるといったことだ。再起動が失敗したら、利用できる場所に変更トランザクションを記録し、データサービスが再び復旧するまでそれを処理する。この良い例がATMである。 ATMは、銀行の財務処理システムへの接続を失った際に、限定された機能ではあるが一定の期間独立に使い続けることが出来る。ATMは人々が自身の口座からお金を引き出すことを許す。ただし、過剰に引き出す事がないよう、金額に制限をかけはする。人々は、口座に入金することもできるが、現在の残高を照会したり、最近の取引の記録を見ることは出来ないだろう。自己回復機能は、エンドユーザーに優れた体験を提供し、組織にかかる運営上の負担を軽減する。

ここまでで、一連の開発プラクティスと機能実装について、概要を見てきた。次回の投稿では、運用作業を合理化する戦略について探検していくつもりだ。

オリジナル：DevOps Strategies – Development 

URL : https://disciplinedagiledelivery.wordpress.com/2015/02/08/devops-strategies-development/

（翻訳：藤井　智弘）

Tweet

Pocket

#本投稿は、US DADコミュニティサイトブログからの翻訳です。

前回の投稿では、ITソリューションの開発とIT運用業務に留まらず、エンタープライズレベルの様々な活動も含めて合理化するものとして、ディシプリンドDevOpsの概要を紹介した。今回は、DevOpsをサポートする戦略を概観することから始めたい。今回の投稿では一般的な戦略を概観することに留め、次回以降開発、運用、リリース管理、データ管理、およびエンタープライズアーキテクチャ戦略を説明していく予定だ。

DevOpsをサポートする”一般的”な戦略を、以下に挙げてみよう：

1.共同作業(Collaborative work)   DevOpsの基本理念は、開発者、運用スタッフ、およびサポート担当者が定期的に緊密に協力しなければならないと謳っている。そこには、彼らがお互いを重要な利害関係者と認識し、積極的に協力する機会を探さなければならないという意図が暗黙のうちに含まれている。アジャイルコミュニティで常識とされるプラクティスに、”オンサイト顧客”（出自はエクストリーム・プログラミングXPだ）がある。これは、アジャイル開発者がビジネスサイドにより近づいていくよう促している。DADアプローチを採用するアジャイリストは、さらに一歩進めた「積極的な利害関係者の参加」プラクティスを実践する。このプラクティスでは、ビジネスサイドの利害関係者だけでなく、運用やサポートスタッフも巻きこんで、彼らのすべてと緊密に連携しなければならないと謳っている。これは双方向で行われる：運用とサポートスタッフは、喜んで開発者と密接に協力しなければならない。
2.自動化されたダッシュボード  自動化されたダッシュボードを使うというプラクティスは、IT インテリジェンスと呼ばれるが、これはビジネス・インテリジェンス(BI)アプリケーションをITに効果的に適用したものだ。これには、開発インテリジェンスと運用インテリジェンスの2つの側面がある。開発インテリジェンスは、メトリックを生成する機能を持った開発ツールを使用する必要がある。例えば、構成管理（CM）ツールは、誰がいつ何のためにチェックイン/アウトしたのかを記録する機能をすでに持っている。継続的インテグレーションツールも同様な機能を持っており、ビルドが行われた時に、どれくらい多くのテストが実行され、どれくらいテストに時間がかかり、ビルドがうまくいったのか、どれくらいのテストがパスしたのか等々の情報を記録する。この種の生データが自動的に分析されダッシュボードに表示される。運用インテリジェンスは、以前議論したアプリケーション監視の一様態である。自動化されたダッシュボードを使うと、組織全体でメトリックを収集するオーバーヘッドを劇的に抑えることができる（すべてを自動化できるわけではないから、完全になくすことは出来ない話なのだが）。自動化されたダッシュボードは、組織のガバナンスチームへリアルタイムの洞察をもたらす。
3.統合構成管理　構成管理（CM）に統合されたアプローチでは、これまで慣例としてきた開発チームがソリューション構築でCMを採用するだけでなく、開発されたソリューションとその他の組織インフラとの間に生じる運用環境の課題も考慮する。これは、開発者にとっては大きな変更となる可能性がある。なぜなら、彼らは現在作業しているソリューション構築の文脈でしかCMを考えていないことが多いからだ。DevOps環境では、開発者がエンタープライズ対応という意識と能力を持ち、より大きな全体像を理解する必要がある。彼らのソリューションは、運用中の他のアセットとどのように連携し、それらを活用するのだろうか？その他のアセットは、開発中のソリューションを活用するだろうか？これらは、開発チームが自らのプロダクトと依存関係のあるあらゆる事を理解し、管理する必要があるだろうということを意味している。統合された構成管理は、新しいリリースがもたらす潜在的な影響を運用スタッフが理解する助けとなる。それによって、新しいリリースの許可を出すタイミングを決定しやすくなる。
4.統合変更管理　組織全体へのサポートを向上させるためにITインフラストラクチャは進化していくが、ITの観点からは、この進化を成功裏にすすめかつ意味のあるものにするためには、変更管理は欠くことの出来ない活動である。多くの技術あるいは類似の技術の様々なバージョンさえ、単一のソリューションの開発に使われるため、プロジェクト·チームレベルでの変更管理には十分な注意が必要だ。DevOpsは、運用に関わるエンタープライズレベルの課題を持ち込むために、統合された変更管理戦略ははるかに複雑になる。非常に多くのソリューションが稼働する運用環境では、同時に相互作用しあうということを考えておくべきだ。統合された変更管理では、組織レベルでの技術の変化の影響を理解するために、開発チームは運用チームと密接に協力しなければならない。このアプローチは、積極的な利害関係者の参加、統合された構成管理、および自動テストといったプラクティスの早い段階で決まる。
5.トレーニング、教育、メンタリング　予想されているように、DevOps戦略を学び適用するためには、手助けが必要になる。
6.継続的改善　DADチームは、自身の経験からだけでなく他の人からも学ぶために努力するので、一緒に作業するやり方を継続的に改善することができる。もちろんそこにはDevOpsへのアプローチ方法も含まれる。
7.ワン・チーム　DevOpsの考え方の重要な側面は、「彼らと私たちの考え方」から「私たちの考え方」にシフトしていることだ。私たちは、単一の、合理的なチームとしてみな協力し合いながら作業する。これを突き詰めた形が「あなたがビルドし、そして実行する」という哲学だ。そこでは、開発も運用もデータ管理チームもなにも分離しておらず、その代わりにプロダクトのライフサイクル全体に責任を持つプロダクトチームがあるだけだ。

次回は、開発チームの戦略を概観する予定だ。

オリジナル：　DevOps Strategies – General
URL :https://disciplinedagiledelivery.wordpress.com/2015/01/27/devops-strategies-general/

（翻訳：藤井　智弘）

Tweet

Pocket