Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Incidents"と題して講演した。主なポイントは次のとおりだ。システムが"正常"運用されている時に、うまくいっている理由を知ることには大きな価値がある。Budget)の監視と管理の支援、インシデント時の"作戦司令室"の運用、インシデント後のレビューの実施があることの紹介から始まった。Netflixに見られるような複雑な分散システムの内部では、インシデントは通常状態である。SREチームはプラクティスやプロセスの整備を完了しているので、インシデントは重要だが"もはや興味の対象ではない"ものだ。インシデントから得られる最も重要な教訓は、障害を克服するためのキャパシティをシステムに構築する方法である。効果的なリカバリ能力には、インシデントの防止よりもはるかに大きな価値があるのだ。言ってもNetflixチームは、カオスエンジニアリングやゲームディ、関連するプラクティスを用いることで、"非常に高いインシデント防止能力"を実現している。Majors氏のことばを引用して、"可用性は構築するものであり"、"ユーザが満足しなければ9をいくつ並べても意味はない"、と指摘した。成功とは、失敗がないということではない。ユーザが望む時にシステムが使用できなければ、99.999パーセントの可用性があっても、実質的な意味がないのだ。続いて、"根本的原因は存在しない"という点が議論された。一般的にインシデントは、複数の要因が組み合わさった"最悪の状況"によって引き起こされるのだ。私たちがインシデントを正しく理解できていないか、ということを思い出させてくれる。インシデントを完全に理解することは、一般的には不可能である。修復した内容が次のインシデントの誘引となることも珍しくない。インシデントは原因から作られるのではない。それらを"見つける"のではなく、構築し、その物語を作り上げることによって、理解を深めることが可能になる。最新のインシデントから学んだとしても、次のインシデントを予測することはできない。複雑なシステムは決定論的ではないからだ。"なぜ(why)"よりも"どのように(how)"を問うことで、インシデントからより多くを学ぶことができる、とKitchens氏は主張する。間違いを防ぐよりも、確実に正しく行なうことの方に大きな価値がある。これを理解するには、通常の作業がどのように行われているかを知らなければならない。従来のインシデント調査では、全体のエクスペリエンスのごく一部しか使用しない上、うまくいっている時間からのデータは無視されることが多い。"ごく普通の日々のパフォーマンスは、知られないまま無視されているのです。"次に氏は、Netflixインシデントレポートから、一連の"コントリビュータとイネーブラ、軽減、リスク"に関する要因を公開した。これらの多くは、インシデントに対処した(またはインシデントに関わった)者ならば誰でも認識できるものだ。knowledge)"による困難を伴う場合が少なくない。Operations"で論じられているように、フォローアップや報告書などの資料において特定されるべきである。インシデントのタイムラインを作成することも有効だ。Outages"が推奨されている。後半のセクションでは、"システムを健全に保つために人々がどれだけ懸命に働いているのか"、"組織内のマネジメントチェーンにこの情報をどのように伝えればよいのか"という問いかけが、聴衆に対してなされた。"すべてが正常"であるという理由から、この種のデータを共有しない組織もあるが、結果としてこれは、通常の運用状態を調査しないことになる、というのがKitchen氏の考えだ。この重要な情報を発見するには対話が必要だが、このコンテキストで人々の協力を得るのは"技術的に最も難しい問題"であるかも知れない。エンジニアにインタビューして、"なぜうまくいかなかったのか?"から"どうやってうまくいっているのか?"に移行することは、困難だが価値のある訓練だ。意図せずにインタビュー対象者を圧迫したり、脅迫したりしないように注意して、効果的な自由回答形式の質問をすることが重要になる。"ここにたどり着いた方法"を構成する記述を引き出てし、彼らの視点から、世界がどのように見えているのかを伝えよう。最後に、インシデント後の対応方法こそが極めて重要である。"もっと注意しよう"、"間違いをしないようにしよう"、"規律が必要だ"といったことばを使ってはならない。Investigations"など、このトピックに関して詳細な情報を提供する一連の書籍を推奨した。Kitchens氏のプレゼンテーションのビデオは、今後数か月間、InfoQで見ることができる。