kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

「未来のチームの作り方」感想

Amazon.co.jp: 「未来のチーム」の作り方 (SPA!BOOKS) eBook: 藤村 能光: Kindleストア

科学的な裏付けなどがあるわけではなく、そのままの形で汎化はできない。 1サンプルとして認識すればヒントはたくさんある。

まず以前読んだ本でもそうだったが、オンサイトのメンバーとリモートの人間で情報格差を作らないことが一つ重要な点に思える。

P180 仕組み9のミーティングをチャット込みでやる手法はよいかも。 書いてあるとおりメリットも多そうだし、これならリモートでやりたい人も参加しやすい。

【WIP】「SRE サイトリライアビリティエンジニアリング」まとめ&感想

第Ⅰ部 イントロダクション

1.2 サービス管理へのGoogleのアプローチ:サイトリライアビリティエンジニアリング

Google内で規定されることになったサイトリライアビリティエンジニアリングとは、いったい 何なのでしょうか。私の説明は単純明快です。SREとは、ソフトウェアエンジニアに運用チーム の設計を依頼したときにできあがるものです。

 

その目的上、SREチームはエンジニアリングに注力することが重要です。常にエンジニアリングを行っていなければ、運用にまつわる負荷が増大し続け、負荷についていくためだけでもチーム にはさらに多くの人数が必要になります。最終的には、運用に注力する旧来のグループは、サービ スのサイズに比例して大きくなってしまいます。

 

DevOpsは、SRE の中核的な 方針のいくつかを、幅広い組織、管理の構造、個人に対して一般化したものと捉えることもでき るでしょう。同様に、SRE をDevOps に独特の拡張を少し加えたプラクティスと捉えることもで きるでしょう。

1.3  SREの信条

概して、SREチームは、サービスの可用性、レイテンシ、パフォー マンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負いま す。

1.3.1 エンジニアリングへの継続的な注力の保証

すでに述べた通り、GoogleはSREが運用作業にかける時間に対して50%という上限を設けてい ます。残りの時間は、コーディングスキルを使うプロジェクトの作業にあてることが求められてい ます。そのため、SREが行う運用作業の量のモニタリングし、超過した運用業務をプロダクト開 発チームへ差し戻します。つまり、バグとチケットを開発チームのマネージャーに割り当て直した り、開発者をオンコールのページャーローテーションに(再度)組み込んだりといったことによっ て実現されています。

 

ページャーが使われたかどうかにかかわらず、すべての大きなインシデントについてはポスト モーテムを書くべきです。ページを引き起こさなかったインシデントについてのポストモーテム は、モニタリングの明らかな欠陥を指していることが多いので、とりわけ価値が高いのです。

1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する

エラーバジェットは、100%を信頼性の目標とすることは、基本的にいかなる場合にも間違って いるという所見から生じたものです

 それでは100%がシステムの信頼性のターゲットとして正しくないのであれば、何が正しい信頼 性の目標なのでしょうか。これは実際のところ、技術的な疑問ではありません。

 

エラーバジェットの利用は、開発とSREとの間の動機付けの構造的な競合を解決します。SRE の目標は、もはや「サービス障害をゼロにすること」ではなくなります。SREとプロダクト開発 者は、機能のリリース速度を最大化するためにエラーバジェットを使うことを目標にします。

1.3.3 モニタリング

この種のメールを 使ったアラートは効果的なソリューションではありません。人間がメールを読み、何らかの対応ア クションの必要性を判断しなければならないようなシステムは、根本に欠点を抱えています。

 

効果的なモニタリングの出力には、3つの種類があります。

アラート

人間が即座にアクションを起こして対応し、状況を改善しなければならないことが生じて いる、あるいは生じようとしていることを知らせます。

チケット

人間がアクションを起こさなければならないことを知らせます。ただしチケットの場合は、 即座である必要はありません。システムが自動的に対処できない状況が生じているものの、 人間が対応するのに数日かかったとしても、その結果障害が引き起こされることはありま せん。

ロギング

この情報を人間が見る必要はないもの、診断もしくはフォレンジックのために記録される ものです。ログは、何かが他に起きない限り、誰かが読むことは期待されていません。

この分類はslackチャンネルの整理に使えるかも

1.3.4 緊急対応

緊急対応の効率を評価する上で、最も関係のあるメトリ クスは、対応チームがシステムを健全な状態に戻すのに要した時間、すなわちMTTRです。

2.1 ハードウェア

サーバー サービスを実装しているソフトウェア。 ... Googleにおけるサーバーという言葉の使い方が、通常とは異なることは承知の上です。

2. ハードウェアを「組織化」するシステムソフトウェア

1つのクラスタ内には大量のハードウェアがあるので、ハードウェア障害はき わめて頻繁に生じることになります。典型的な場合、1つのクラスタでは1年間で数千のマシンに 障害が発生し、数千のハードディスクが壊れます。

2.2.1 マシン群の管理

BorgがMapreduceのようなバッチジョブもWebサーバーのようなデーモンも実行するのは意外。 これはKubernetesに通じるものがある。デーモンも不意に死ぬから扱い一緒ってことか?

要求した以上のリソースをタスクが使おうとすると、Borgはそのタスクをkill し、再起動させ ます(これはゆっくりとクラッシュを繰り返すタスクは、まったく再起動されないタスクよりも好 ましいことによります)。

若干最後の訳が怪しいけど、頻繁に再起動されてもよいという意味かな。

2.4  Googleのソフトウェアインフラストラクチャ

Googleのすべてのサービスは、Stubbyと呼ばれるリモートプロシージャコール(RPC)を使っ て通信します。Stubbyのオープンソースバージョンとしては、gRPCがあります。

2.5 Googleの開発環境

モノレポ戦略に関する言及。これ現実的なのかなあ。 うちでの導入を考えてもいいかも。

第Ⅱ部 原則

この部の最初の章である「3章 リスクの受容」は、「SREの仕事とはどういうものか」、そして 「なぜそのような仕事をするのか」についての幅広い見地を得たい方にとっては、最重要となる必 読の章です。この章では、リスクの視点、すなわちリスクの評価、管理、エラーバジェットを使っ たサービス管理に有益な中立的アプローチといったことを通じてSREを見ていきます。

3 リスクの受容

はある一線を越えると、信頼性を 向上させることはサービス(及びそのユーザー)にとって、むしろマイナスになることが分かって います。過度の信頼性は、コストに跳ね返ります。安定性を最大化しようとすれば、新しい機能の 開発や、ユーザーへのプロダクトの提供速度が制限され、コストが劇的に増大することになりま す。そしてチームが提供できる機能の数が減っていくことになります。

 

99%の信頼性を持つスマートフォンを 使っているユーザーには、サービスの信頼性が99.99% の場合と、99.999%の場合との違いは分から ないのです。

つまり、信頼性を極端にあげようとするとコストは累乗で跳ね上がるが逆にメリットは小さくなる。つまりROIのRが加速度的に下がり逆にIは加速度的に上がる。割りに合わない。

3.1  リスクの管理

繰り返し信頼性を増していこうとすると、ある回は前回に比べて100倍のコストがか かることもあります。このコストには2つの特徴があります。

  • 冗長なマシン/コンピュートリソースのコスト

  • 機会のコスト

3.2 サービスリスクの計測

サービスのリス クについて言えば、潜在的な要素のすべてを1つのメトリクスにまとめる方法は、一見しただけで は分かりません。サービスの障害は、ユーザーの不満、損害、信頼の喪失、直接的または間接的な 売上の損失、ブランドや評価へのインパクト、望ましくない報道などを含む、さまざまな影響を及 ぼす可能性があります。これらの要素の中には、明らかに計測が難しいものがあります。

 

この問題を扱いやすくかつ一貫性のあるものとするため に、私たちは計画外の停止時間に注目しています。

 

私た ちはサービスを十分信頼できるものにするために努力はしますが、必要以上に信頼性を高めようと はしません。すなわち、可用性のターゲットを99.99% とした場合、それを超えようとはするもの の、大幅に超えようとはしません。

 

通常のアプリケーションではすべてのリクエストが同一というわけではありません。新規ユー ザーのサインアップリクエストに失敗するということは、バックグラウンドで行われている新着 メールのポーリングに失敗することとは意味合いが異なります。とはいえ多くのケースでは、エン ドユーザーの視点から見て、全リクエスト数に対する成功したリクエスト数として計算された可用 性は、予定外の停止時間の近似値として妥当なものです。

CVの失敗はSLOというよりはチケット(1.3.3)として扱ったほうがよさそう。

私たちはサービスの可用性のターゲットを四半期単位で設定し、それらのターゲットに対して週 単位、もしくは日単位でパフォーマンスを追跡します。

3.3.1.1 可用性のターゲットレベル

可用性を決めるときの指標・参考

  • ユーザーが期待するサービスのレベル。
  • サービスが直接的に収入(Googleの収入もしくはGoogleの顧客の収入)につながってい るか。
  • サービスは有料か、あるいは無料か。
  • 市場に競合がある場合、その競合が提供しているサービスのレベル。
  • サービスはコンシューマ向けか、それとも企業向けか。

3.4 エラーバジェットの活用

実 際、Google SREの非公式なモットーは「希望は戦略にあらず」です

 

例えば、プロダクト開発者はテストはほどほどにしてプッシュの速度を上げたいと考え、SRE はそれに反対しているような場合、エラーバジェットが判断のガイドになってくれます。エラーバ ジェットが大きければ、プロダクト開発者はリスクを多めに取ることができます。エラーバジェッ トがほとんど尽きているなら、プロダクト開発者もそれを使い切ってしまってローンチができなく なるリスクを取りたくはないので、自身でもっとテストをしたり、リスクの速度を下げることにな るでしょう。すなわち、プロダクト開発チームが事実上自己統制するようになるのです。プロダク ト開発者はエラーバジェットを知っており、自分自身のリスクを管理できます(もちろん、そうな るためにはSLOに抵触した場合に、ローンチを実際に止める権限をSREチームが持っている必要 があります)。

 

計測されているSLOが、ネットワークやデータセンターの障害によって減ってしまった場合は どうするのでしょうか。こうしたイベントもエラーバジェットを消費します。結果として、その四 半期の間、新しいプッシュの数は減らされることになるかもしれません。稼働時間に対する責任は 全員が共有するものなので、この削減はチーム全体が支持します。

 

エラーバジェットは、過剰な信頼性ターゲットのコストの一部を、柔軟性の不足やイノベーショ ンの速度の遅さという観点から照らし出すものでもあります。新しい機能のローンチに関してチー ムが問題を抱えているなら、SLOを緩める(すなわちエラーバジェットを増やす)ことによって、 イノベーションを加速させるという選択肢を取ることもできます。

4.1.1 指標

多くのサービスでは、重要なSLIとしてリクエストのレイテンシを考慮します。これは、リクエ ストに対するレスポンスを返すまでにかかった時間です。他の一般的なSLIとしては、エラー率や システムスループットがあります。

 

SLOを選択し、ユーザーに公表するということは、サービスの挙動に対する期待を設定すると いうことです。この方策によって、例えばサービスの速度が遅いといったような、サービスの所有 者に対する隠れた不満を減らすことができます。

4.1.3 アグリーメント

通常、SREはSLAの構築には関わりません。これは、SLAがビジネスやプロダクトに関する判 断に密接に関わるものだからです。

とはいえうちのような小さな組織ではそんなことは言ってられない。

4.2.2 指標の収集

多くの指標のメトリクスは、サーバーサイドで収集するのが自然です。 ... とはいえ、 システムによっては、クライアント側での収集の仕組みが必要なこともあります。これはクライア ント側で動作を計測しないと、サーバーサイドのメトリクスには影響せず、ユーザーにだけ影響を 及ぼすような種類の問題を見落としてしまうかもしれないためです。

Skylight、Datadog側に寄せられないものか。

4.3.2 ターゲットの選択

ターゲット(SLO)の選択は、純粋に技術的な活動というわけではありません。これは、プロ ダクトやビジネスの事情が、SLI とSLOのどちらにも(そしておそらくSLAにも)反映されるは ずだからです。

4.3.4 SLOによる期待の設定

過剰達成を避ける

これを実践できるイメージはまだ僕の中にはない。

5.1 トイルの定義

また、行わなければならない管理上の雑務もありますが、これはトイルに分類されるべきではあり ません。それはオーバーヘッドです。

 

トイルとは、プロダクションサービスを動作させることに 関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値 を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。

今までの自分の認識とずれているためここでのトイルの定義はよく頭に入れておいたほうがよさそう。

5.2 トイルは少ない方が良い理由

さらに、新しいSREを採用する際に、私たちは上で述べた50%ルールを引用し、SREが典型的 な運用の組織ではないことを約束します。この約束を守るために、私たちはSREの組織やチーム を、単なる運用チームに退化させないようにしなければならないのです。

ここの分類や50%へ維持することなどは実践したいところだけど優先度がわからん。

6.3 モニタリングにおける妥当な期待値の設定

私たちは、閾値を学習したり、自動的に因果関係を検出しようとす るような「魔法の」システムは避けています。 ... 複雑な依存階層の扱いについては、これまでGoogle SREは限定的にしか成功したことがありま せん。私たちは、「データベースの速度が落ちているなら、データベースの速度低下のアラートを 発する。そうでなければ、Web サイトの全体的な速度が落ちているというアラートを発する」と いうようなルールは滅多に使いません。

Googleがこのような実践的で現実的なプラクティスを行っているというのは以外だけどとても安心できる。やはりAI技術を監視の分野へ応用するのは難しいということなのかな。

6.8 適切な計測の粒度の選択

この辺はSaaS任せでいいか

6.9 可能な限りシンプルに、ただしやり過ぎないこと

収集されてはいても、事前に作成されたダッシュボードのいずれにも表示されず、どのア ラートにも使われていないシグナルは、削除の候補です。

この観点は良い気がする。

Googleの経験では、メトリクスの基本的な収集と集計は、アラート及びダッシュボードと合わ せて、比較的スタンドアローンのシステムとしてうまく動作します

メトリクスの収集は、アラート・ダッシュボードとセット。

また、この見方によってはっきりさせられる区別もあります。それはすなわち、原因よりも症状を捉 えることに労力を費やした方が良いということです。

監視で原因を正確に捉えることの難しさからこれは来ているのだと思う。

6.11.2 Gmailスクリプト化された予測可能なレスポンスの手動送信

こういった意見の対立がチーム内に生じるのはよくあることですが、それはしばしば、チーム自 身の原則に対する不信感が生じていることを反映しています。すなわち、チームメンバーの中に は「ハック」を実装して、適切な修正までの時間を稼ぎたいと考える者もいれば、そのハックが忘 れられたり、適切な修正の優先度がいつまでも引き下げられたままになったりするのではないかと 6.12 まとめ 69 心配する者もいたのです。本当の修正を行う代わりに、問題を覆い隠すようなパッチを行うことに よって、メンテナンス不能な技術的負債のレイヤーを構築してしまうことは簡単に起こるので、こ の心配はもっともなことでした。マネージャーや技術のリーダー達は、発端となったページの「苦 痛」が去った後でも、潜在的に時間を要する長期的な修正を支援し、優先順位付けすることによっ て、長期的な本物の修正の実装に対する中心的な役割を果たします。

刺さる話。

7.1.5 時間の節約

しばしばエンジニア は、自動化をしたりコードを書いたりするときに、それによって省略できる手作業と、それを書く のに必要な労力とを比較して、十分な価値があるのか迷うことになります。見逃されやすいのは、 タスクをいったん自動化でカプセル化してしまえば、そのタスクは誰でも実行できるようになると いうことです。したがって、時間の節約の効果は、その自動化を使うかもしれない全員に及びま す。オペレータを運用から分離することには、大きな価値があるのです。

7.2 Google SREにとっての価値

Googleはその規模性から自働化はほぼ脳死で選択できる。一方で僕らのようなプレイヤーはまだそこまでには至っていない。僕らはあるタスクを自動化するべきかはそのたびに考慮する必要がある。

7.3.2 自動化のクラスの階層

こういった自動化のステップはすべて価値あるものであり、自動化のプラットフォームも本当に それ自体価値あるものですが、理想の世界では、外部に自動化の仕組みを持つ必要すらないでしょ う。実際のところ、グルーとなるロジックを持たなければならないシステムよりも、グルーとなる ロジックをまったく持つ必要がないシステムの方が良いのです。

自働化より自律化。Kubernetesのような考え方だなー。

7.4 自分の仕事の自動化:何もかも自動化する

MySQLでの開発の世界では、MySQLインスタンスが動作環境のスタック中で最も安定してい るコンポーネントと仮定するのが当然のことだったので、この転換によって、JDBCのようなソフ トウェアをカスタマイズして、障害が起こることが前提になっている私たちの環境に対する耐性を 高めなければならなくなったのです。

このGoogleは脱却したMySQLの呪いは、MySQLを使い続けているすべてのアプリケーションすべてを依然呪い続けている。このためにRDSを使ってすら再起動・フェイルオーバーにリスクが生じしている(アプリケーション側がうまくハンドリングできない)。

7.5 苦痛の緩和:クラスタのターンアップへの自動化の適用

初期の自動化は、クラスタの素早い提供に焦点を当てたものでした。このアプローチは、パッ ケージの配布やサービスの初期化といった面倒な問題に対し、SSHを創造性豊かに使うことで対 応していました。この方針は、初期にはうまくいきましたが、こういった型にはまっていないスク リプトは、技術的負債でできたコレステロールのようなものになっていきました。

フフってなる。

7.5.3 特化する傾向

ここ難しい。セクションの真意がよくわからない。

サービスを動作させるチームの責任範囲から自動化のコードのメンテナンスと実行を外すことに よって、私たちは不格好な組織的インセンティブを作ってしまっていました。

せやね、この辺のインセンティブ設計は重要で、組織をデザインするときは考慮する必要がある。

7.8 自動化のすすめ

本章の例を読んで、読者は何らかの自動化に手を伸ばす前に、Googleのようなサイズにならな ければならないと判断したかもしれません。

  1. メリットは時間の節約だけではなく、だれでも実行できること、引き継ぎの簡単化などが挙げられる。

うっ、図星。

8.1 リリースエンジニアの役割

リリースエンジニアは、プロジェクトのリリースが確実に一貫して再現可能な方法で行われるよ うにするために、私たちのツールの使用方法のベストプラクティスを定義しています。

これ僕もやってんな。

8.3.3 テスト

リリースエンジニアリングは、プロ ジェクトのリリース判定基準に相当するテストターゲットをそのまま継続的なビルドでもテストさ せることを推奨しています。私たちは、すべてのテストに成功した最新の継続的テストビルドのリ ビジョン番号(バージョン)でリリースを作成することも推奨しています。

CIテストの方針。リリース判定基準のテストをCIビルドでもするべきという方針。

リリースプロセスの間、私たちはリリースブランチを使ってユニットテストを再実行し、すべて のテストにパスしたことを示す監査証跡を生成します。

ほー、もう一度テストするのか。これはdocker時代にはちょっと古いかも。

継続的テストのシステムを補完するために、私たちはパッケージ化されたビルドの成果物に対し てシステムレベルのテストを行う、独立したテスト環境を使っています。これらのテストは、手動 で走らせることも、Rapidから走らせることもできます。

8.3.6 デプロイメント

私たちの目標は、デプロイメントのプロセスをサービスのリスクプロファイルに適合させること です。

たしかに、必ずしもカナリアデプロイが必要とも限らない?後の文の例だと開発環境や小規模サービスでは一律デプロイしてはと書かれている。

この章、結構Google固有の大規模かつ自作ツールを使った話が多く、before k8sでもあるのであまり有用に使えそうな話がない。

第Ⅲ部 実践

P110 War14

これBeyond corpのことっぽい。

P117 SMTPとBorgmonのプロトコルは全く似ていないのが面白い

たしかに。SNMPが監視の道具として事実上死んでいることを示唆しているよう

P134 根本原因の分析、改善、ポストモーテムの執筆のようなフォローアップ、バグの修正といったオンコールのインシデント対応にかかる時間の平均は6時間

P135 SREがサポートしているシステムの開発チームは通常24/7のオンコールローテーションに加わります。

「リモートチームでうまくいく」感想&まとめ

How toだけ書くのは本質から離れるという意見もあるが、やり方を書かないと忘れる。 のでHowを書く。

Amazon.co.jp: リモートチームでうまくいく eBook: 倉貫義人: Kindleストア

  1. 場所は離れていても同じ時間帯に働く

  2. 朝来たら挨拶を書く、帰るときはお疲れさまでしたと書く。

  3. カメラで存在を確認する。
  4. timesチャンネルのようなもので独り言を簡単につぶやける環境を作る。

上記はすべて論理出社、物理的な出社をシミュレートするためにある。

掲示板の機能はissueで代用できている気がする。

  1. リモートチームでの信頼関係の気づき方

一緒の問題・タスクに向かうことで信頼は築かれる。 タスク管理はzenhubでOKな気がする。 スケジュールはcalendarでOK? いつから、何日という発言は不要にしてgoogle calendarへ一本化するのは有りかも。

リモートワーカーを少数派にしない

これは難しい。ただでさえインフラという他のチームとの協業が必要な部署なのにその上リモート化を推し進める。 契約上の話もあるし厳し目。

5. 毎日の習慣とリズムを作ろう

オンカメラ、10分程度の朝会はやったほうがいいかも。時間は要相談だが10時くらい?

一番最後のリモートワークに至るまでの道は今の自分たちの参考になった。 リモートワークだと全員が平等に情報を得られるようにというのが繰り返し書かれているけど、それが今すぐ難しいとき、それをどうやって実現まで持っていくか、過程状態でも上手くやってくにはどうすればいいのかのヒントになりそう。

個人的リファクタリング史

年齢 できごと
15 プログラミングを始める。何もわからずひどいコードのパッチワークで半端なものすらできない
16 自分のコードがひどいことはわかるのだがどう改善すればいいかわからない状態
17 デザインパターンやテストの概念とともにリファクタリングの概念と出会う
17 Eclipseの自動リファクタリング機能に衝撃を受ける。リファクタリングの威力を初めて実感
18 ~ 24 リファクタリングを自動テストやOOPなどと組み合わせつつ実践
24 就職。最初に入った現場でリファクタリングがまったく実践・考慮されておらずひどいコードがそのまま放置されていることに衝撃
25 自分が初期から書いていないプロダクトでレビューの文化(仕組み)がなく自動テストもない場合、よそ者がリファクタリングするのは非常に困難だと実感。またリファクタリングの価値を説明できず理解してもらえなかったことにも失望
25 継続的にリファクタリングを試みるが主に本番稼働しているコードを変更することへの恐怖・リスクからチーム内で同意が得られない。それらを自分たちで書いたメンバーはコードの構造の特殊な癖も十分に理解しており改善に対するインセンティブが薄かった
26 ~ 27 新規プロダクトでたくさんのコードを書く。納期優先でひどいコードも量産。リリース後にリファクタリングを行ったが構造が複雑でテストがあってもリファクタリングが劇的には進まず、そもそもそのプロダクトに関して改修案件が全く来ずコード改善の効果が低かった。この辺でリファクタリングの価値について疑問を持つ
2x ファウラーだかの言葉で「リファクタリングするより1から作り直したほうが早いときはそうするべき」というものに衝撃を受ける。それまでどんなにひどいものでも作り直すよりかはリファクタリングしたほうが早いと思っていたのだが、基本設計がひどい場合はリファクタリングでも改善できない、そういったケースがあることを初めて認識する(それまでリファクタリングは良くないコードに対する銀の弾丸だと思っていた)
2x 確率的に犠牲的 - steps to phantasien ここらへんからもリファクタリング・改善一度ではないのだなと認識
2x (これもファウラーかIDDDあたりだったはず) 良いものを作るには最初から正しく作らないとだめだ1という主張を読む。今までのプロダクト開発を振り返るに否定する材料がない。リファクタリングを無力に感じる
30 ~ 31 自分の書いた新規コードと過去のメンバーが書いたコードが混在するプロダクトで、リファクタリングとコード修正のサイクルが初めてまともに回る。これはPull Requestの仕組みでレビューが制度化されたこととリファクタリングについての共通認識をチーム内で醸成できたこと、そしてなにより機能追加や改修の前にその地ならしとしてリファクタリングをするというやり方がチームへ受け入れられたことが大きいと思っている。一方で開発したプロダクトは商業的には成功せず、このときリファクタリングなんてかなぐり捨てて新規機能開発へ全力を注いだほうが組織としては価値があったのではないかという疑念は残った
32 リファクタリングは相変わらず大好きだが年をとってステークホルダーへ説明責任を果たす役割が増えた今、その価値をどう説明するか、リファクタリングをどう活かすかについて悩んでいる

「りろんはしってる」状態

ある技術やツール、フレームワーク、ライブラリなどについて入門記事や概要の解説記事は読んだがまだチュートリアルもこなしていない状況。

入門記事や概要解説の記事などは理想的な条件が前提であったり業務であるシチュエーションより大幅に単純なシチュエーションが扱われる事が多い。また機能や利便性について針小棒大にかかれていることもよくある。そのため多くの場合実際に使ってみなければ自分たちの現場で使えるかはわからない。実態と自分のイメージが大きくずれていることもよくある。

この状態で実際の現場への導入イメージや活用の細部を話し合うのは非常に危険。せめてチュートリアルだけでも一度こなしたほうがよい。

元ネタ

f:id:den8:20191231183103j:plain
"よつばと! 第3巻 第19話 「よつばとぞう」 - 8月14日" より

よつばと! 3 (電撃コミックス) | あずま きよひこ |本 | 通販 | Amazon

AWSサンドボックスアカウント運用のすすめ

AWSサンドボックスアカウントとは?

AWS基盤上でサービス開発をしている企業において、サービス開発に携わるすべてのエンジニア1が自由にAWSのサービスを試用・実験・検証できるAWSアカウント。

作り方

AWSの機能としてサンドボックスアカウントなどという物があるわけではないので以下の手順で作ります。

  1. それぞれの社内規定に従いサンドボックスアカウント用の予算を確保します
  2. それぞれの社内手順に従いAWSアカウントを作ります2
  3. すべてのエンジニアがAdministratorAccess権限3でログインとawscliコマンドを打てるようにします
  4. サンドボックスアカウント用に AWSのコスト予測アラートを設定します
  5. 下記のサンドボックス利用ルールとログイン方法を社内のエンジニアに周知します

利用ルール

MUST

  • 仕事上使う、使いたい、使えるか検討したいAWSサービスがあれば本番環境アカウント・開発環境アカウントなどではなくここでそのサービスを試行(テスト)してください

SHOULD

  • サンドボックスアカウント上に作られたリソースは一日ごとにすべて削除される、またはされる可能性があります4。それでも問題のない使い方をしてください

RECOMMENDED

  • リソースが日毎に消える可能性があるためCloudFormationやTerraformなどのInfrastructure as a Codeを利用することをおすすめします5

SHOULD NOT

  • 不必要なまでにコストがかかる実験・試用はしないでください
  • 大きなコストがかかるが必要性のある実験・試用をする場合はサンドボックスアカウントの運用責任のある部署へ先に一方ください。調整します

MUST NOT

AWSサービスの試行・検証・テストは自由ですがサービスへの攻撃を含むテストはAWSへの申請なしにしてはいけません。こちらで詳細を確認して可能なテスト種別であればAWSへ申請をして実行してください。

目的

tl;dr

  • 新サービス・新機能・使ったことのないサービスの試行を促進することで開発を高速化
  • 失敗してもいい空間(アカウント)を作ることで試行そのものを安全に高速化
  • 開発環境AWSアカウントなどで実験してはぐれインスタンスなどを残さないため

長い説明

AWSのサービスを実際に使用してみることなくサービス開発で利用することは非常に難しいです。AWSのリリースやドキュメントを読んだだけでサービスへ組み込もうとするとイメージと実体が乖離していたりパフォーマンスや機能などが期待と大きくずれていたりします。 そのためシステム設計の前にしろ後にしろどこかのフェイズでAWSのサービスを試行することになりますが、この際いくらかの問題を感じてきました。

  • インフラ構築中の開発環境アカウント/本番環境アカウントなどで試行する
  • → 試行中のリソースと実際のシステムの一部のリソースが混じり合う
  • → 間違ってシステムの一部のリソースを削除してしまったりする
  • → 試行自体が抑制される
  • → 知らないAWSサービスや新しいサービスが使いにくくなる
  • → システムがEC2インスタンスベースで構築される
  • → 運用コスト・保守コストが高くなる

こういったことが開発組織では起こりがちです。 こうなるとエンジニア含め会社全体が嬉しくないので、それを解決するために既存AWSアカウントと分離したサンドボックスアカウントという手段を考えました。


  1. クラウドエンジニアやインフラエンジニア、バックエンドエンジニアなどと呼ばれる普段からAWSを触ることが多い職種だけではなく、フロントエンドのエンジニアやアプリのエンジニアなどクラウド基盤を直接・間接問わず使用するすべてのエンジニア

  2. AWS Organizationを使うのがおすすめです

  3. 請求情報などを平エンジニアに見せたくないなどといった要望がある場合は制約を加えてもいいかもしれませんが基本的に悪手です。各々のエンジニア自身に自分たちの運用しているサービスのコスト感を意識させる意味でもコスト系も開放することをおすすめします

  4. コストへの配慮のため。お金じゃぶじゃぶの企業はこの項目いらないかも

  5. 実際のシステム構築でCloudFormationやTerraformなどを使ってもらいたいことも一因です