Engineeringの本質的理解とOSS貢献」があります。Traps」という記事が素晴らしく良かったので日本語訳して、価値提供を少しできたらいいなと思って書いてます。対象記事はこちらです。Engineeringに関わる業務をしています。Engineeringにコミットをしています。以下の記事を対象にしています。Traps)という題目で発表したものを記事化したものです。このコミュニティ自体はNora氏によると、Youtubeをはじめとする、媒体にはアップされてないみたいです。investigation”)にインスパイアされて、今回の記事を作成したみたいです。Engineeringの体系的な理解は、以前のChaosKubeの記事で説明してるので説明はしません。気になる方は以下の記事をご覧ください。システム工学など多岐に渡ります。ケーススタディ本記事で軽く説明されているケーススタディを紹介します。有名なカオス的な実験である最初の有人宇宙飛行計画であるアポロ1号を対象にしています。アポロ1号とは、アメリカの人類初の初めての月面着陸であるアポロ計画のミッションです。ja.wikipedia.org発射リハーサルは1967年2月21日に、アポロのクルーと一緒に命令とサービスモジュールのテストのため計画されていました。コマンドモジュールから発火して、3人のクルーが犠牲となりました。出火の原因は、初期型アポロ司令船の設計および構造における広範囲な致命的な欠陥に起因するものであるとされました。ドアのハッチが本来ならフライト中の安全を守るものなのだが、出火のときには開かなかった。ロケットは当初、完全に燃料を積んでいたわけではないので、テストは行われていなかったのである。私達エンジニアは直接的には全員が人命を扱っているわけではありませんが、それでもビジネスには必ず直結していると思います。Engineeringが必要であり、それをもって、私達の障害に対する行動に対して自信を持つことができます。NASAの実際の調査のドキュメントはこちらのリンクからご覧になれます。Engineeringの8つの罠ここから本題です。記事で紹介されている実際の8つの罠について見ていきましょう。Engineering自体の「費用対効果」として計測するには、見つけた脆弱性を一つの指標として使うことは、とてもありふれていて、自然な方法でしょう。Engineeringが成功しているとは限らないのです。この論文中の一つの格言にErrorは怠惰の計測していて、リスクではないとあります。組織として脆弱性の数をOKRとして定義しているなら、間違いになります。Engineeringの本当の効果を得られづらくなります。1回この商品を含むブログを見るこの本では、統計の解釈を誤ると、結論をミスリードしながらも、実際にはよいパフォーマンスをだしていると信じさせることを実証しています。Engineeringとは脆弱性を見つけるツールのようなものではなくて、私達が見つける脆弱性を通して信頼性を求める旅へ出かける背中を押すようなものです。ここでトップハイライトされている一文があるので紹介します。信頼性とは、変更や障害へ対応し、重要な機能を維持するためのシステムの機能であるここでシステムは「人」も含めての意味です。Engineeringの一つです。信頼性工学のファンデーションはこちらにあるので、興味がある人は参照するのが良いかもしれません。Engineeringのための準備でチームの2/11のエンジニアだけが会議に参加していたが、それが問題を引き起こした実例があるそうです。実験下のシステムに対して、多様なメンタルモデルを議論することは大事でしょう。Engineeringを実行するには規範的なルールがあるこれは、誰もが否定するでしょう。Engineeringには存在しません。Engineeringの結果を知って、ルールを制定することがゴールではありません。成功の一部は、関係を構築して、システムのトレードオフ、専門的な知識をどのように進歩させるか、作るかに対して理解することです。脆弱性があるから修正を要求するのではなくて、なんでそのようなことになるのかという文脈をサービスオーナーに提供することが大事です。修正のバックログを追加するのではなくて、サービスオーナーにトレードオフを理解してもらってどのように対処するかを自律的に判断してもらうのが賢いでしょう。脆弱性を修正するべきだ。実験がされる可能性のあるサービスや依存関係に設定を提供するツールを開発していたそうです。ゴールとはサービスオーナーにサービスの重要な情報を提供することで、RPCタイムアウトが低すぎるなど一見、すぐにはわからないような知見を提供していました。以下のようなフィードバックがサービスオーナーからあったそうです。requestを出してくれないのか実際にはタイムアウトを代表するように、それらは人間の専門知識が必要であり、人間が判断する必要があります。「何がいい」、「何がもっといい」というような概念は、自動化はしづらいく、UXに対しての自動化は多くの考慮が必要です。重要なインサイトとして、結果的に自動で直してそれがエラーになった場合に、どのように修正をするべきか誰が知っているのでしょうか。繰り返しにはなりますが、修正のバックログを追加するのではなくて、サービスオーナーにトレードオフを理解してもらってどのように対処するかを自律的に判断してもらうのが賢いでしょう。Engineeringではない非Production環境でChaos実験をすることは、重要なだけでなくて、プロダクション環境で実験をする前や、実験をベストプラクティスに基づいて実験をするときに必要です。著者は強く、サンドボックス環境で実験を練習してみてほしいとのことです。自動化の観点で自動化によるプロセスを実行より、実験を自動化するプロセスのほうが学びがあるということです。Engineeringを行った最も価値のある報酬になります。黄金率としては「実験の前、実験中、実験の後はどれも平等に、かつそれぞれ固有の注目があるべき」とのことです。障害は、誰かの「どのようにシステムが動いてほしい」といったような精神的なモデルを見直す機会です。チームごとによっても違う可能性は高いです。chaos実験をデザインして、ファシリテートをするような人はサービス外部の人であることが望ましいです。Engineeringとは、複数のチームからいくつかの人が、システムに対して議論して、実験をデザイン、実行することが最も価値のあるリターンを生みます。安全は後から心配して、まずはカオスな状態を生むのが大事であるアポロ1号のハッチドアが内圧によって開かなかったのは、本来ハッチドアとは安全を守るものであることを考えれば皮肉です。これらは一般的でなくて、「脆弱性防御」という名前がつけています。重要なのは、脆弱性をテストするために防御をを理解することが重要です。防御の脆弱性はとても見抜くのが難しいです。Engineeringとは、防御の脆弱性を見つけることに約立ちます。カオス自体は簡単ですが、安全性は難しいです。失敗させることは簡単ですが、それから「反応をする」ということは難しいのです。ここでいう反応とは、システム的なものだけではなくて、例えばダッシュボードの可視化性、ログのチェックなども含まれます。chaos実験はシステムの理解がなくても実行をすることができるこれは暗闇の中で的に発砲している状態と何も変わりありません。トレース、障害パターンなどを知る必要があります。Engineeringとは、定常状態を定義するところから始まります。満たすべき要件が揺れているようでは、正しい実験はできません。Engineeringに対する有用な知見がシェアされていたので、すぐにこの記事に取り掛かりました。Engineeringが通過点としてあると思います。今回は非常に良い機会になりました。カオスだった平成最後の日に。アドラー心理学によれば、私たちは常に目的をもって行動し...2018-12-14CircleCIでSpinnakerのデプロイメントパイプラインをデプロイするどうも、もうすぐ大学卒業の@timtimtim1026です。»プロフィール学生エンジニア。忘れてしまうので備忘録です。flaskでServerlessにホストするTelepresence概論スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。