Link to original article From Green Data Centers and Red Numbers – Sustainability in IT The development and operation of software takes place in data centers — and they can be anything but green. Politics and society increasingly demand companies become more sustainable. Resolutions such as the Paris Climate Agreement have set strict guidelines in …
From Green Data Centers and Red Numbers – Sustainability in IT Read More »
Link to original article SolarWinds: Top 3 predictions for 2023 Better IT energy management The increase in energy costs across Europe are affecting organisations of every size. As a result, 2023 will see organisations examining new ways to lower costs and improve IT efficiency. In the past, considerations like efficiency and lower running costs were …
Link to original article What is “AIOps?” The Importance of Artificial Intelligence in IT Operations 前回の記事では、組織がAIOpsを導入する必要がある背景やAIOpsの定義について説明しました。今回は、AIOpsの導入に必要な5つのステップと、AIOpsを導入するメリットについて説明します。 AIOpsの5つの重要なステージとは？ AIOpsの主な用途としては、パフォーマンス監視、異常検知、根本原因分析、ITサービス管理、自動化などが挙げられます。AIOpsには、図2に示すような複数の段階があります。 各段階には、生データの収集から変換や分析を経て、問題を修正するためのアクションの実行に至るまで、明確な目的があります。定量的な観点としてAIOpsは、IT環境における問題の検出、調査、解決にかかる時間の短縮を目指します。 1.データの取り込み AIOpsの最初の段階は、サーバー、ネットワーク、アプリケーションなど、さまざまなソースシステムからデータセットを収集することです。問題の検出と解決にかかる時間を最小限に抑えるには、できるだけリアルタイムにデータを取得することが重要です。この要件は、ストリーミングインジェストをサポートすることが重要であることを意味します。 また、履歴データを残すことも重要です。履歴データは、AIOpsの機械学習モデルを改良し、キャパシティープランニングやセキュリティ侵害の調査など、他のタスクをサポートするために活用できます。 データを取り込む上でもう一つ重要な側面は、集約したデータの正規化または標準化です。ソースシステムによっては、同じ種類のデータに対して微妙に異なるデータ構造を使用している場合があり、データを共通の構造にマッピングして、後の段階で行う高度な分析をサポートすることが重要です。 2.データ統合 AIOpsの第2段階は、データの統合です。これは、異なるソースからのデータを関連付けることで、各ソースシステムから得られる多様な情報に基づいて、根本原因の分析を実現するということを意味します。 例えば、あるアプリケーションでは、アプリケーションのパフォーマンスと負荷に関する一連のメトリクスと、アプリケーション処理における重要なイベントを記述したログメッセージが生成される場合があります。メトリクスとログを時系列で共通のダッシュボードにそろえることで、イベントと依存関係の相関関係のパターンを見つけやすくなり、アプリケーションパフォーマンス監視（APM）の洞察をより良く伝えることができます。 3.イベント相関 イベントの相関は、システムの状態を把握するために有効なイベントを特定するプロセスです。相関の目的は、膨大な数の注目すべきイベントの流れの中から、興味深いイベントの「点」を関連付けることです。例えば、あるネットワークデバイスがトラフィックの増加を示すメトリクスを報告し、その後にロードバランサーが同様の増加を報告したとします。 次に、ロードバランサーのクラスター内のサーバーからCPUとメモリーの使用率が異常に高いという報告があったとします。通常ロードバランサーは、CPU使用率が定義されたしきい値を超えると、クラスターに仮想マシン（VM）を追加することになっています。しかし、そうならない場合は、リソース不足を解消するために早急な対策が必要です。 4.問題の検出 ロードバランサーがクラスターのVM数を増やすことに失敗するのは、イベントの相関関係によって問題を検出できる例であり、相関関係にあるデータに対して、パターンマッチングやその他のAI技術を適用した例でもあります。人間がパターンを定義することもできますが、機械学習のアルゴリズムは、大量のITデータから関心のあるパターンを特定する異常検出やその他の予測分析に長けています。こうした技術によってAIOpsシステムが学習し、検出できる問題の範囲を拡大することができます。 5.問題の修正 AIOpsパイプラインの最終段階は、検出された問題を修正することです。ロードバランサーに障害が発生した例では、クラスターにリソースを追加することができます。もし、この事象が進行中のセキュリティ侵害に関連している場合、AIOpsシステムはネットワークポートをブロックし、セッションを終了させ、攻撃者が悪用するシステムの既知の脆弱性にパッチを充てるなどの措置を講じることができます。 More publications:
Link to original article Legacy systems and security will continue To Dominate the Agenda for Public Sector IT Professionals When it comes to protecting computer systems and networks, the “biggest cyber risk is complacency, not hackers.” That’s according to John Edwards, the UK’s Information Commissioner who warned that companies are leaving themselves open to cyberattacks …
Link to original article in Japanese What is the definition, role, and benefits of SRE, and how does it differ from DevOps? 近年、ソフトウェア開発には、スピードと柔軟性が求められています。このような状況において、IT部門にはエンドユーザーに提供するソフトウェアやサービスの品質を確保するための実践的な手法が必要になるため、Googleが提唱したSRE（サイト・リライアビリティ・エンジニアリング）が注目されています。 これまでIT部門では、システムアドミニストレーター（シスアド）が行うことと、アプリケーション開発者が行うことの間に明確な線引きが存在していました。しかし、ソフトウェア開発手法の一つであるDevOpsの採用により、セキュリティや安定性を重視するIT運用と、スピードやビジネスの変化への適応を重視する開発とのギャップが狭まりました。 SREの概念とその役割は、IT部門のシスアドと似ていますが、開発スキルや経験が多少加わります。アプリケーションやサービスがサービルレベル契約（SLA））の基準を満たしているか、自動拡張サービスのオートメーションが構築されているかに加え、SREの担当者は開発部門が主に担当するソフトウェアエンジニアリングを通じた運用上の問題に対処します。 従来の優れたシステム管理者は、システム上に存在するできるだけ多くの運用タスクを自動化するため、共有や修正をするシェルスクリプトのツールキットを常に所持していました。しかし、Kubernetesのような自動化およびオーケストレーションツールを実装するためのフレームワークは、SRE の役割に移行するにつれ、さらに多くの開発作業を必要とするようになりました。 以下、SREの定義を明らかにした上で、その役割について説明していきます。 SREの定義に必要な要素 SREは、従来のシスアドと開発者の役割を兼ね備えているため、SRE担当者がアプリケーション全体をゼロから書き上げることはないでしょう。SRE担当者は、bash シェルスクリプトや Pythonなどの言語を使用してタスクを自動化します。また、アプリケーションスタックに一元管理が可能なオブザーバビリティを組み込んで主要なメトリクスを測定し、環境全体の可観測性の向上に貢献します。 SREの一般的なコンセプトの一部として、定義したサービスレベル目標 (SLO) との整合性を確保するために、サービスレベル指標 (SLIs) を基準にしたレイテンシーなどのメトリックスを使用し、システムの信頼性を測定することが推奨されます。 SLOを定義する際は、レイテンシー、エラー率、全体的なスループットなど、主要なSLIsを指定して、到達可能な目標を設定する必要があります。また、ダウンタイムコストを定義し、アプリケーションのアーキテクチャを決定するのに役立てることができます。 このダウンタイムコストは、SREの重要な概念です。すべてのサービスが100％遅延なく稼働することは期待されていません。もし何かのサービスが利用できない場合は、他の提携サービスの持続が求められます。これは、マイクロサービス・アーキテクチャの重要な要素です。 例えば、検索サービスが利用できない場合、Webサイトやアプリケーションの残りの部分は通常通り機能する必要があります。このダウンタイムやエラーにまつわる予算は、SRE 担当者と開発チームの協同における新機能にも関連しています。 また、ある時間帯にダウンタイムコストのほとんどが消費されてしまったとします。この場合、開発チームは新機能の導入を、安定した環境におけるリスクを回避するため、予算をオーバーする心配がなくなるまで待つかもしれません。 つまり、ITシステムの恒久的なフル稼働を目指すのではなく、一定のサービスレベルを保証する（ダウンタイムを考慮した）SREを採用することで、システム管理者は開発と保守のバランスを取りながら運用することを目指すのです。 SREの役割と任務 SREの担当者は通常、時間の50％以上を運用に費やしません。SREのメソッドにおいて、この数字は、エンジニアの労苦や挫折を避けるためのポイントとなり得ます。残りの50％の時間は、新機能の作成、システムのスケーラビリティの向上、アプリケーションのアラートなどの手動タスクの自動化など、プロジェクト業務に充当されるでしょう。 サービスが停止している場合、それは開発チームが対処すべきです。特定のタスクのオーナーシップを明確にすることで、SRE担当者は、インシデント発生後のレビュー、オンコールローテーションの計画と最適化、他のエンジニアリングチームと共有するためのランブックの知識文書化など、他のタスクを実施することができるようになります。 また、この方法はエンジニアリングチーム内のサイロ化を回避し、より一貫したインシデント対応を促進するのに役立ちます。 SREとDevOpsの比較 SREは純粋に開発のためのものではありませんが、DevOps プロセスで重要な役割を担っており、組織がDevOpsのメリットを得ることをサポートします。SREの役割自体は、DevOpsのプラクティスを実装したものと考えられます。 DevOpsにおけるSREの役割は、DevOpsチームが使用するアプリとサービスが、必要なときにエンドユーザーとアプリケーションから利用できるようにすることです。SREとDevOpsの間には重複する部分が多く、この2つはよく一緒に議論されますが、明確な違いがあります。 DevOpsは、ソフトウェアの開発と実装のためのアジャイル手法とベストプラクティスに基づいた一連の原則と定義されています。その名が示すように、DevOpsはソフトウェアを作る側と、それらのソフトウェアを稼働・維持する側とのギャップを埋めるものです。SREと同様に、DevOpsはチームの文化と人間関係の上に築かれ、チームがより速い開発サイクルとバグ発生の防止を実現するのを支援します。 SRE担当者は、ソフトウェア開発およびインフラストラクチャの管理に関する知識を共有してベストプラクティスに関わる推奨を行い、DevOpsを支援します。コード管理やモニタリングで DevOpsソフトの改善を直接促すこともできます。また、開発チームと運用チーム間のコミュニケーションギャップをさらに縮小し、インフラ全体を改善します。 SREを実践するメリット …
What is the definition, role, and benefits of SRE, and how does it differ from DevOps? Read More »
