[レポート] 高周波企業のような運営を #ENT203 #reinvent

こんにちは韓です。LasVegasでre:Inventに参加しています。 今回は以下のセッションに参加いたしましたのでレポートをします。

セッション概要

サマリー:

High-frequency enterprises embrace cloud computing as a flywheel for frequent value delivery. This requires tighter alignment with business unit stakeholders to increase agility and pace of innovation. In this session, we explore the potential for transformation that comes with cloud adoption and discuss how some of the world’s leading enterprises were able to transform and quickly deliver business value outcomes. We also explore organizational and technology best practices that you can implement to become a high-frequency enterprise.

和訳

高周波企業は、頻繁に価値を提供するためのフライホイールとしてクラウドコンピューティングを採用しています。 これには、俊敏性とイノベーションのペースを高めるために、事業部門の関係者との緊密な連携が必要です。 このセッションでは、クラウドの導入に伴う変革の可能性を探り、世界をリードする企業のいくつかがどのように変革し、ビジネス価値の結果を迅速に提供できたかについて議論します。 また、高周波企業になるために実装できる組織および技術のベストプラクティスも検討します。

登壇者:

• Joseph Chung - Director - Enterprise Strategist, Amazon Web Services

レポート

エンタープライズのスペクトラムは「変化しないのが普通」と「変化が普通」な時期とがある。

エンタープライズ領域ではその境目に近づくと多くのプレッシャーを感じる。

• 90%の企業は何らかの形でデジタル化に取り組んでいる
• 16％は、スケーリングに関する大胆な戦略でデジタル破壊に対応していると感じている

• 67% のビジネスリーダーは競争に勝ち抜くためにより多くのデジタル化能力が必要だと信じている

• 高頻度に実践を行っている企業は、従来の低頻度の企業よりも46倍頻繁に価値を提供します。

なぜ、エンタープライズは動きが少ないことに安堵を覚えるのか

• 不具合があったり安定性を欠くアプリケーション
• セキュリティやリスク、コンプライアンス
• 大きな賭けは失敗を生みやすい

そして大プロジェクトにおいてその感覚が当てはまる

計画前は平穏な時期だが、

スコープが拡張すると

リスクが拡大する

典型的なのは変化のあるところで手動プロセスがあるところ - 拡張したスコープの境目 - プロジェクトの極大期

そして壮絶な開始を迎える

---

平穏な時期から、変化に富む時期への変革は以下のようなことが起こる

• 大きな賭けは失敗の元
  • → 処理単位を小さくし頻繁にリリースを行う
• ビジネスの根幹を堅守する
  • → 継続的に見直しと改善を行う
• HiPPOベースのデザイン設計
  • → データ駆動型の意思決定、十分なテストと計測行って
• ビジネスとITは別のサイロ
  • → ビジネスとITとが同一のチーム
• 大規模な機能セットとシステムの無秩序な増加
  • → 関連性のための絶えず優先順位付けと検証を実施
• ソフトウェアやプロセスは必ずしも快適ではない
  • → アイデアから実装までのリードタイムを短縮
• 最適な運用状態を前提とした計画
  • 攻撃や不具合を前提とする

• From:
  • 長期にわたって開発に苦労する大きな賭け
• To:
  • 処理単位を小さくし価値提供を加速する

• From:
  • ビジネスの根幹を死守、現状維持
• To:
  • 継続的な見直しでレガシーシステムやプロセスを改善

• From:
  • HiPPOベースの意思決定と壮大な発表
• To:
  • データ駆動型の意思決定。その中でアイデアと要求は仮説となりテストと計測がなされる

• From:
  • IT部門とビジネス部門にまたがるサイロ。IT部門はあたかも別ベンダのよう
• To:
  • ビジネスと技術にまたがるチーム。作るべきもののみに注力できるオーナーがいる

• From:
  • 大規模な機能セットとシステムの無秩序な増加。その価値は未知数
• To:
  • 関連性のためにバックログに常に優先順位を付けて検証することにより、行われていない作業量を最大化する

• From:
  • ソフトウェアを買いプロセスを組み立てる。でも快適ではない
• To:
  • アイデアから実装までのリードタイムを短縮。スピードを止めてしまうゲートではなく、スピードを落とさずにエラーを防止するガードレールを自動敵に制御する

• From:
  • 「最適な状態」を全体とした計画で未知の事象には目を向けない、根本原因にのみ焦点を当てる
• To:
  • 障害のテスト、自己修復可能なチェックの埋め込み、攻撃、障害、および欠陥が発生すると想定

このような変革を起こすには以下のような手順を行う

1. 仕事を分割。 モノリスからマイクロサービスへ。
2. 従業員に投資する。 そして彼らをあなたの顧客により近づける。
3. 煩雑な手続きを自動化。終わりにするために
4. 組み込む、外付けにしない。攻撃や障害を想定して。

作業分割

• リソース利用は返って平準化するようになる。

• 成果物のサイズは小さくする
• 常に変更する
• 未完了の作業を最大化する

組み込む、外付けにしない

• 弾力的で柔軟なシステム
• 漫然と流れていくようなことを防ぐ
• セキュリティの文化を築く

作業を分割する

• 価値提供を頻繁に
• リスクの影響範囲を小さく
• 段階的な投資

そうだ、モノリシックなサービスを一度に分割しよう

• 数百万行以上のコードでできているモノリシックなサービス
• 150以上に分割されている本番サービス

アンチパターン特性 - 10年モノの収益重視のコード。変更するには危険すぎる - モノリス全体に影響を与えたり変更したりせずに拡張するのが難しい長期実行プロセス - 単一アカウントの障害によりワークフロー全体がブロックされてしまう。しかも中身はよくわからない

分割する方法は - 使い慣れたAWSのクラウドネイティブなサービスでレガシーアプリケーションを動かす - 迅速かつ安全な開発を行うために機能を分割 - 徐々にタスク単位でリファクタリング - 最終的にはクラウドで全て、あるいはハイブリッドなアプリケーションに

個々のタスクをLambdaに置き換えていきます、そしてStep-functionはモノリスからサーバレスに至るまでずっと利用可能で、効果的で回復力のあるシステムを迅速に構築することができます。

従業員に投資をする

• 必要なチームがあります -- スキル教育
• ビルドしたものを実行する -- DevOpsが有効
• システムではなく、顧客価値を中心に再調整

• 変化が通常であるようなカルチャーのシフト
• 手渡しによる技術的負債をなくす
• 組織をより顧客に近づける

• かつては大規模なプロジェクトで多くの人が血が参画; ビジネスアナリスト、プロダクトマネージャ、プロジェクトマネージャ、デザイナ、開発者、テスター、構成管理担当、運用・サポート

• プロジェクトは小規模に。

  • 小さく中央集権的でない組織は快適
  • 作るべきものを担当し実行する

煩雑な手続きを自動化

原則

• 門番をなくして自動制御とする
• 再利用可能な部品を標準化する
• "終わり" は リリースを意味する

効果:

• チームが独自のタイムラインでアジャイルIT資産を操作できるようにする
• アイデアから実装までの時間を短縮する
• 手続きは無駄にしない

これらを実践すると

• 1/5 の障害発生
• 440倍の速さ、コミットしてデプロイに対して
• 46倍の頻度のデプロイ
• 44%増の新機能やコードに費やせる時間

自動化によるセキュリティはクラウドのスピードと機敏さにマッチする

ベライゾンは今や1,000ものビジネス上クリティカルなアプリケーションやデータベースをAWSに移行している。まるでクラウドプロバイダのようだ。

クラウドネイティブなセキュリティとリスクおよびコンプライアンスのプロセス

• 基本的な設定ルールを解析
• デプロイと検証で設定をテスト
• 本番リリースが可能かチェックする

• セキュリティポリシーを伴ったコンプライアンス
• 必要に応じて実行できる能力
• 新たなルールを即座に拡張できる
• 組織全体へスケール

---

Werner Vogels (Amazon.com CTO)の曰く、

失敗はつきもの。どんなことだって最終的には失敗するものだ。

組み込め、外付けするな

障害が起きた際、対象となるプロセスが長い場合影響範囲も大きくなる。 逆に、小さなプロセスの場合は影響範囲は狭くなる。

原則

• 障害をテストする
• コンプライアンスとセキュリティを埋め込む
• セキュリティや信頼性を全ての人のものとする

いかに多くの大企業が弾力性のことを考えているか

理論的には、全てがうまくいく場合、想定されている災害は乗り切ることができます。 それはどのように機能しますか？

動きの速い組織はどのように回復性を考えているか？

カオスエンジニアリングの原則

カオスエンジニアリングは、本番環境のシステムが 過酷な環境に耐えうる能力 で 自信を構築 する ための、分散システムにおける 実験しつづける 規律である。

実験することで障害の影響が軽減されることが確認できるでしょう

クラウドを利用することで容易にコンプライアンスを管理することができます

• Travex社は、安全で準拠したシステムを構築する長年の経験を持っていますが、オンプレミスインフラストラクチャでは市場投入までの時間が問題でした。
• クラウドを使用して、これまでで最も安全なシステムを構築し、リリース頻度を増やしました。

高周波は文化の継続的な変革でもある

事前:

• クラウドでチームを訓練
• ツールを構築/購入
• 承認サイクルを短く

事後:

• 高周波は継続的な学習
• 改変しシンプルなシステムに
• サイクル時間をゼロに近づける

この旅のバックボーンは、エンジニアのクラウド機能を成長させるだけでなく、IT組織全体に文化的な変化をもたらし、準備を整えて継続的に未来を構築する学習プログラムを構築することです。

Mahoud El Assir -- Verizon SVP & CTO

だれでもない、あなたのための未来の予定を変えましょう！

まとめ

アメリカで急激に成功している企業の文化とデジタルトランスフォーメーションをクラウドで実践している内容の紹介で、エンジニアよりもCTOや情報責任者といった方向けのセッションでした。

クラウドにすべきか悩んでいる皆様の助けになれば幸いです。