Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Miles氏が,可観測性とカオスエンジニアリングは"密接に関連している"と考える理由が論じられている。エンジニアがカオス試験を実施する場合には,試験の対象とする下位システムに関して多くの問いかけをする必要が生じるはずだ,と氏は主張する。このためには,実行中のシステムを監視し,理解できることが重要な前提条件となる。そこで,このレポートでは,試験の実施と合わせて,メトリクスの収集やログ,トレースに関する指針も簡潔に示されている。ChaosIQ.ioのCEOであるMiles氏は,32ページからなるこのレポート執筆時にはHumioのチームで開発作業に従事していたため,同チームも執筆を支援している。Tracingデータの出力,といったものだ。Schmidt氏に話を聞いた。カオスエンジニアリングは、開発者やセキュリティチーム、運用管理者が、失敗や脅威の注入という形で意図的かつ慎重に試験を行うことによって、システムの理解を向上し、再調整し、前進することを可能にします。システムに対する理解度の向上は、顧客とユーザのよりよいエクスペリエンスや,ビジネス成果の向上にもつながります。state)'を定義することから始めよ",と述べられている。ここからShumidt氏は,カオス試験を始めるにおいては,"システムの正常時を確認し,試験を実施することでその正常状態からどれほど逸脱するかを検出する"ために,システムを監視する能力を開発することが重要なのだ,と主張する。その上で氏が強調するのは,Humioの顧客と作業した時に,カスタマイズ可能で粒度が細かく,ほぼリアルタイムなメトリクスとログが,試験の影響をよりよく理解することにつながる,という知見を得たことだ。Londonでプレゼンテーションを行い,効果的なカオスエンジニアリングプラクティスの実践を行うための大きな前提条件として,極めて厳格なインシデント管理,モニタリング,ダウンタイムの影響を測定する能力,の3つを主張した。Engineering"レポートでは,このトピックの広範なオーバービューを紹介するだけでなく,試験時に監視すべきメトリクスを識別することの重要性についても議論されている。Systems"という記事の中で,それぞれ論じている。Allspaw氏は,"可観測性"という用語が当初の意味(実証的調査に裏付けらていること)から離れたものになっている点を指摘し,関連する人的要素の重要性を無視してはならない,と警告している。InfoQは先日,そのMiles氏と席を共にして,カオスエンジニアリングと可観測性の話題に関して議論をした。Russさん,こんにちは。今日は時間を頂いて,ありがとうございます。Chaos)でしょう。Toolkitを入手し,オンラインチュートリアルをいくつか試して,自分自身でカオス試験をいくつか作ってみることをお勧めします。自身のシステムの可観測性に疑問を持つようになるでしょう。Engineering"といった書籍が次のステップになります。最後に、参加することによって無償で記録を比較したり,多くのアドバイスを受けることのできる,素晴らしいコミュニティもいくつかあります。Communityがあります。ToolkitやPlatformを使っているのであれば,私たちのチームやコミュニティのSlackもあります。カオスエンジニアリングは,システムに信頼と信用を構築することを目指す,エキサイティングな旅です。カオスエンジニアリングを,より堅牢でレジリエントな,そして最終的には信頼性と安全性を備えたシステムの構築を支援する重要な思想であり規律である,と考えている私たち全員が,あなたがカオスエンジニアリングを導入し,継続していく手助けをする手段として,これらのコミュニティが存在するのです。今の質問の中で,キーワードは"前に"です。カオスエンジニアリングに着手するかどうかとは関係なく,システムが良好な可観測性を備えるのは非常に望ましいことですから,正確には前提条件ではないのですが,カオスエンジニアリングと可観測性という2つのアプローチの組み合わせは,極めて良好に機能するのです。カオスエンジニアリングを実施する前から,システムがある程度の可観測性を備えているケースもあります。カオスエンジニアリング試験で何らかの逸脱が明らかになり,システムの弱点を診断する必要が生じた場合には,これが非常に役に立ちます。一方で,カオスエンジニアリング試験を開始したことが"強制力"になって,それまでなかったシステムの可観測性改善の必要性がクローズアップされる場合もあります。このような理由から,私たちの経験では,優れた可観測性はカオス試験の重要な前提条件ではないのです。カオスエンジニアリングを考える場合には特にシステムの可観測性の欠如が顕著に現れる,ということなのです。この2つの技術は,時間とともに相互に発展し,互いに強化し合うようになることでしょう。興味深いのは,これはカオスエンジニアリングが,他の非機能的ないし運用中心のシステムを改善する,優れた"強制力"となる理由でもある,という点です。カオスエンジニアリングはこのように,忘れられがちな,あるいは後回しにされがちな懸念を眼前に突き付けることが少なくありません。運用システムに責任や関係を持たない人たちにまで,このような課題を強く意識させ,それによって対応する堅牢性や回復機能を設計し,システムに実装することを可能にするのです。一言で言うならば,カオスエンジニアリングは,すべての人々をより運用状況に敏感なシステムオーナにするものであって,それゆえにシステムの可観測性は,大きなメリットを即時に得られる機能のひとつなのです。カオスエンジニアリングが組織内で失敗する理由はたくさんあります。思想に対する理解不足から,対立的な関係で他のチームを混乱に陥れようとするカオスエンジニアまで,さまざまです。カオスエンジニアリングを不適切に行えば,その規律が拒絶されることにもなりかねません。ChaosIQチームでは,組織内のすべての人たちが,最終的にはカオスエンジニアリングを実践し始めると考えています。カオスエンジニアリングは選ばれた一部の人々のテクニックではありません。ミッションクリティカルなビジネス・システムを所有するすべての人にとって有用な考え方であり,規律なのです。これは当然,中小規模の組織においても,大規模なカオスエンジニアリングの課題があるという意味でもあります。規模が大きくなるほど,カオスエンジニアリングアプローチの失敗する確率も高くなるのです。カオスエンジニアリングが失敗する可能性のひとつは,カオスエンジニアリングがサプライズとして実施される時です。これはあらゆる規模の導入で見られます。これはつまり,試験を実施したことで誰かが驚いたとすれば,それはすべての人々にとって気まずいものであるため,そのような試験は二度と行いたくないという要求につながる場合が多い,ということなのです。組織全体のゲームデーなどの一環として,カオス試験そのものでチームを驚かせてみるのも効果的です。人々やプラクティスやプロセスの弱点を探る目的で,不穏な事態にチームがどう対応するかを確かめるため,適用される条件の正確な内容を同僚に告げない場合もあります。このような条件はサプライズであるとも言えるでしょう。ゲームデー自体はサプライズではありません。これは重要なポイントです。サプライズではないカオス試験の実施にも,これとは別の意義があります。カオス試験の実施によって影響を受ける可能性のある人はすべて,そのカオス試験がいつ,何に対して,さらに理想的には,何のために実施されるのか,知ることができるべきだからです。Toolkitとプラットフォームの試験形式,プラグイン可能なカオスエンジニアリング可観測性ツールを組み合わせることで,このようなチーム間および組織レベルの可視化が可能になり,カオスがサプライズになる危険性と,その時点で起こり得る不適切な対応を回避することができます。そのためには,多くの点において,チームの規模やカオスエンジニアリング能力に関係なく,カオス試験の実施をシステム全体の可観測性の枠に含めることが,このような落とし穴を避けるためには不可欠なのです。カオスエンジニアリング試験はシステムの一部でもあるので,運用中のシステムの他の側面と同じように,その活動について知ってもらい,目に見えるものにすることが,広く受け入れられるために重要なことです。Observability"は,HumioのWebサイトでダウンロード公開されている。参照には登録が必要だ。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。