Ansible によるディスク交換の自動化

こんにちは、みんな。 私は OK で主導的なシステム管理者として働いており、ポータルの安定した運用を担当しています。 ディスクを自動的に交換するプロセスをどのように構築したか、そしてどのようにして管理者をこのプロセスから除外してボットに置き換えたかについて話したいと思います。

この記事は一種の音訳です 公演 HighLoad+ 2018にて

ディスク交換プロセスの構築

まずいくつかの数字

OK は何百万人もの人々が利用する巨大なサービスです。 7 つの異なるデータセンターにある約 4 台のサーバーによってサービスが提供されます。 サーバーには 70 を超えるディスクが含まれています。 積み上げると高さ1km以上の塔が出来上がります。

ハードドライブは、最も頻繁に故障するサーバーコンポーネントです。 このようなボリュームでは、30 週間に約 XNUMX 枚のディスクを交換する必要があり、この手順はあまり快適なルーティンではありません。

事件

当社ではインシデント管理を本格的に導入しています。 それぞれのインシデントを Jira に記録し、解決して整理します。 ユーザーに影響を与えたインシデントが発生した場合は、必ず集まって、そのような場合の迅速な対応方法、影響を軽減する方法、そしてもちろん再発を防ぐ方法を検討します。

ストレージデバイスも例外ではありません。 それらのステータスは Zabbix によって監視されます。 Syslog 内のメッセージの書き込み/読み取りエラーを監視し、HW/SW RAID のステータスを分析し、SMART を監視し、SSD の摩耗を計算します。

以前にディスクを変更した方法

Zabbix でトリガーが発生すると、Jira でインシデントが作成され、データセンターの適切なエンジニアに自動的に割り当てられます。 これは、すべてのハードウェア インシデント、つまりデータ センター内の機器の物理的な作業が必要なインシデントに対して行われます。
データセンターエンジニアは、ハードウェアに関する問題を解決し、サーバーの設置、保守、解体を担当する人です。 チケットを受け取ったエンジニアは仕事に取り掛かります。 ディスク シェルフでは、彼は個別にディスクを交換します。 しかし、必要なデバイスにアクセスできない場合、エンジニアは勤務中のシステム管理者に助けを求めます。 まず、ディスクを回転から外す必要があります。 これを行うには、サーバー上で必要な変更を加え、アプリケーションを停止し、ディスクをアンマウントする必要があります。

当直のシステム管理者は、勤務シフト中のポータル全体の運用に責任を負います。 彼はインシデントを調査し、修復を行い、開発者が小さなタスクを完了するのを支援します。 彼はハードドライブだけを扱っているわけではありません。

以前は、データセンターのエンジニアはチャットを通じてシステム管理者と通信していました。 エンジニアは Jira チケットへのリンクを送信し、管理者はそれをフォローし、作業のログをメモ帳に記録しました。 しかし、チャットはそのようなタスクには不便です。そこでの情報は構造化されておらず、すぐに失われます。 また、管理者はコンピュータから離れ、しばらくの間リクエストに応答せず、エンジニアがディスクのスタックを持ってサーバーの前に立って待機することもできます。

しかし、最悪だったのは、管理者が全体像、つまりどのようなディスク インシデントが存在し、どこで問題が発生する可能性があるかを把握していなかったことです。 これは、すべてのハードウェア インシデントをエンジニアに委任しているためです。 はい、管理者のダッシュボードにすべてのインシデントを表示することができました。 しかし、それらは多数あり、管理者が関与したのはそのうちの一部のみです。

さらに、エンジニアは特定のサーバーの目的やドライブ間の情報の分散について何も知らないため、優先順位を正しく設定できませんでした。

新規交換手順

私たちが最初に行ったのは、すべてのディスク インシデントを別のタイプの「HW ディスク」に移動し、「ブロック デバイス名」、「サイズ」、および「ディスク タイプ」フィールドを追加することでした。これにより、この情報がチケットに保存され、チャットで常にやり取りする必要はありません。

また、XNUMX つのインシデントの間は XNUMX つのディスクのみを変更することにも同意しました。 これにより、将来の自動化プロセス、統計収集、作業が大幅に簡素化されました。

また、「責任管理者」欄を追加しました。 そこには勤務中のシステム管理者が自動的に挿入されます。 エンジニアは誰が責任者であるかを常に確認できるため、これは非常に便利です。 カレンダーにアクセスして検索する必要はありません。 このフィールドにより、管理者の助けが必要なチケットを管理者のダッシュボードに表示できるようになりました。

すべての参加者がイノベーションから最大限の恩恵を受けられるようにするために、私たちはフィルターとダッシュボードを作成し、それらについて参加者に伝えました。 人は変化を理解すると、それを不必要なものとして遠ざけなくなります。 エンジニアは、サーバーが配置されているラック番号、ディスクのサイズと種類を知っておくことが重要です。 管理者はまず、これがどのような種類のサーバーのグループなのか、またディスクを交換するとどのような影響があるのか​​を理解する必要があります。

フィールドとその表示の存在は便利ですが、チャットを使用する必要がなくなるわけではありません。 これを実現するには、ワークフローを変更する必要がありました。

以前はこんな感じでした。

これは、管理者の助けを必要としないエンジニアが今日も仕事を続ける方法です。

まず最初に新しいステータスを導入しました 調査する。 エンジニアが管理者が必要かどうかをまだ決定していない場合、チケットはこのステータスになります。 このステータスを通じて、エンジニアはチケットを管理者に転送できます。 さらに、ディスクを交換する必要があるがディスク自体が現場にない場合、このステータスを使用してチケットにマークを付けます。 これは CDN とリモート サイトの場合に発生します。

ステータスも追加しました レディ。 チケットはディスク交換後に引き継がれます。 つまり、すべてがすでに完了していますが、HW/SW RAID はサーバー上で同期されています。 これにはかなり長い時間がかかる場合があります。

管理者が作業に関与する場合、スキームはもう少し複雑になります。

ステータスから Open チケットは、システム管理者とエンジニアの両方が翻訳できます。 ステータス中 進行中 管理者はディスクを回転から外し、エンジニアが簡単にディスクを引き出せるようにします。サーバーの特定のグループに応じて、バックライトをオンにし、ディスクをアンマウントし、アプリケーションを停止します。

その後、チケットは次の場所に転送されます 変更する準備ができました：これはエンジニアにディスクを引き出せるという合図です。 Jira のすべてのフィールドはすでに入力されており、エンジニアはディスクのタイプとサイズを知っています。 このデータは、以前のステータスに基づいて自動的に入力されるか、管理者によって入力されます。

ディスクを交換すると、チケットのステータスは次のように変わります。 かわった。 正しいディスクが挿入されていること、パーティショニングが完了していること、アプリケーションが起動されていること、および一部のデータ回復タスクが起動されていることを確認します。 チケットはステータスに転送することもできます レディ、この場合、管理者がディスクを回転させたので、管理者が引き続き責任を負います。 完成図は次のようになります。

新しいフィールドを追加することで、作業がはるかに楽になりました。 彼らは構造化された情報を扱い始め、何をどの段階で行う必要があるかが明らかになりました。 優先順位は管理者によって設定されるようになったため、より重要なものになりました。

チャットの必要はありません。 もちろん、管理者はエンジニアに「これはもっと早く交換する必要があります」または「もう夕方ですが、交換する時間はありますか?」と手紙を書くこともできます。 しかし、私たちはこれらの問題について毎日チャットでコミュニケーションすることはもうありません。

ディスクはバッチで変更され始めました。 管理者が少し早く出勤し、自由時間があり、まだ何も起こっていない場合は、交換用に多数のサーバーを準備できます。フィールドに記入し、ローテーションからディスクを削除し、タスクをエンジニアに転送します。 エンジニアは少し遅れてデータセンターに来て、タスクを確認し、倉庫から必要なドライブを取り出してすぐに交換します。 その結果、代替率が向上しました。

ワークフロー構築時に学んだ教訓

• プロシージャを構築するときは、さまざまなソースから情報を収集する必要があります。
  管理者の中には、エンジニアが自分でディスクを交換していることを知らなかった人もいました。 MD RAID 同期はエンジニアによって処理されると考えていた人もいましたが、エンジニアの中にはアクセス権さえ持っていない人もいました。 一部の一流のエンジニアはこれを実行しましたが、プロセスがどこにも説明されていなかったため、必ずしもそうではありませんでした。
• 手順はシンプルで理解しやすいものでなければなりません。
  人にとって多くのステップを念頭に置くのは困難です。 Jira の最も重要な隣接ステータスはメイン画面に配置する必要があります。 これらの名前は変更できます。たとえば、「進行中」「変更準備完了」と呼びます。 また、他のステータスは目障りにならないようにドロップダウン メニューで非表示にすることができます。 しかし、人々を制限せず、移行する機会を与える方が良いでしょう。
  イノベーションの価値を説明する。 人々が理解すると、新しい手順をより受け入れやすくなります。 私たちにとって、人々がプロセス全体をクリックするのではなく、それに従うことが非常に重要でした。 次に、これに自動化を構築しました。
• 待って、分析して、理解してください。
  手順の構築、技術的な実装、会議とディスカッションに約 XNUMX か月かかりました。 そして実装にはXNUMXか月以上かかります。 人々が徐々にこのイノベーションを利用し始めている様子を目の当たりにしました。 初期段階では否定的な意見が多かったです。 しかし、それは手順自体やその技術的な実装とは完全に独立していました。 たとえば、ある管理者は Jira ではなく Confluence の Jira プラグインを使用していたため、いくつかの機能を利用できませんでした。 彼に Jira を見せたところ、一般的なタスクとディスクの交換の両方で管理者の生産性が向上しました。

ディスク交換の自動化

私たちはディスク交換の自動化に何度か取り組みました。 すでに開発とスクリプトがありましたが、それらはすべて対話型または手動で動作し、起動が必要でした。 そして、新しい手順を導入して初めて、これがまさに私たちに欠けていたものであることに気づきました。

置換プロセスは複数のステージに分割され、各ステージには特定の実行者とアクションのリストがあるため、一度にすべてを自動化するのではなく、段階的に自動化を有効にすることができます。 たとえば、最も単純な段階である準備完了 (RAID/データ同期の確認) は、ボットに簡単に委任できます。 ボットが少し学習したら、ディスクを回転させるなど、より重要なタスクをボットに与えることができます。

動物園のセットアップ

ボットについて話す前に、インスタレーションの動物園へ少し足を延ばしてみましょう。 まず第一に、それはインフラストラクチャの巨大なサイズによるものです。 次に、各サービスに最適なハードウェア構成を選択するように努めます。 当社には約 20 種類のハードウェア RAID モデルがあり、そのほとんどが LSI と Adaptec ですが、バージョンの異なる HP と DELL もあります。 各 RAID コントローラには独自の管理ユーティリティがあります。 コマンドのセットとその発行は、各 RAID コントローラのバージョンごとに異なる場合があります。 HW-RAID が使用されない場合は、mdraid を使用できます。

ほとんどすべての新規インストールはディスク バックアップなしで行われます。 システムをサーバーではなくデータセンター レベルでバックアップするため、当社ではハードウェア RAID とソフトウェア RAID を使用しないように努めています。 しかし、当然のことながら、サポートする必要があるレガシー サーバーも数多くあります。

RAID コントローラー内のディスクが RAW デバイスに転送される場所もあれば、JBOD が使用される場所もあります。 サーバーにシステム ディスクが XNUMX つある構成があり、交換する必要がある場合は、同じバージョンの OS とアプリケーションをインストールしてサーバーを再インストールし、その後、構成ファイルを追加してアプリケーションを起動する必要があります。 また、バックアップがディスク サブシステム レベルではなく、アプリケーション自体で直接実行されるサーバー グループも数多くあります。

合計で 400 を超える独自のサーバー グループがあり、約 100 の異なるアプリケーションを実行しています。 このような膨大な数のオプションをカバーするには、多機能の自動化ツールが必要でした。 できれば、それを書いた人だけがサポートできるように、単純な DSL を使用してください。

Ansible を選択したのは、エージェントレスであるため、インフラストラクチャを準備する必要がなく、すぐに開始できるためです。 さらに、Python で書かれており、チーム内で標準として受け入れられています。

一般スキーム

XNUMX つのインシデントを例として、一般的な自動化スキームを見てみましょう。 Zabbix は sdb ディスクに障害が発生したことを検出し、トリガーが点灯し、Jira でチケットが作成されます。 管理者はそれを見て、それが重複でも誤検知でもないこと、つまりディスクを変更する必要があることを認識し、チケットを「進行中」に転送しました。

Python で書かれた DiskoBot アプリケーションは、Jira に定期的に新しいチケットをポーリングします。 新しい進行中チケットが表示されたことがわかり、対応するスレッドがトリガーされ、Ansible でプレイブックが起動されます (これは Jira のステータスごとに行われます)。 この場合、Prepare2change が起動されます。

Ansible はホストに送信され、ディスクを回転から削除し、コールバックを介してアプリケーションにステータスを報告します。

結果に基づいて、ボットはチケットを変更準備完了に自動的に転送します。 エンジニアは通知を受け取り、ディスクを変更しに行き、その後チケットを Changed に転送します。

上で説明したスキームによれば、チケットはボットに戻り、ボットが別のプレイブックを起動し、ホストに行き、ディスクを回転させます。 ボットがチケットをクローズします。 万歳！

次に、システムのいくつかのコンポーネントについて説明します。

ディスコボット

このアプリケーションは Python で書かれています。 JQL に従って Jira からチケットを選択します。 チケットのステータスに応じて、後者は対応するハンドラーに進み、次にステータスに対応する Ansible プレイブックを起動します。

JQL とポーリング間隔は、アプリケーション構成ファイルで定義されます。

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

たとえば、「進行中」ステータスのチケットのうち、「ディスク サイズ」フィールドと「デバイス名」フィールドが入力されているチケットのみが選択されます。 デバイス名は、プレイブックを実行するために必要なブロック デバイスの名前です。 ディスク サイズは、エンジニアが必要なディスク サイズを知るために必要です。

また、Ready ステータスのチケットのうち、dbot_ignore ラベルが付いているチケットはフィルターで除外されます。 ちなみに、このようなフィルタリングと重複チケットのマーク付けと統計の収集の両方に Jira ラベルを使用します。

プレイブックが失敗した場合、Jira は dbot_failed ラベルを割り当てて、後で分類できるようにします。

Ansible との相互運用性

アプリケーションは次の方法で Ansible と通信します。 Ansible Python API。 playbook_executor にファイル名と変数のセットを渡します。 これにより、Ansible プロジェクトを Python コードで記述するのではなく、通常の yml ファイルの形式で保持できるようになります。

また、Ansible では、*extra_vars* 経由で、ブロックデバイスの名前、チケットのステータス、および発行キーを含む callback_url を使用します。これは HTTP でのコールバックに使用されます。

起動ごとに、group_vars が適用されるように、XNUMX つのホストとこのホストが属するグループで構成される一時インベントリが生成されます。

以下は、HTTP コールバックを実装するタスクの例です。

コールバックを使用して Playbook を実行した結果を取得します。 これらには次の XNUMX つのタイプがあります。

• Ansible コールバック プラグイン、プレイブックの実行結果に関するデータを提供します。 開始されたタスク、正常に完了したタスク、または失敗したタスクについて説明します。 このコールバックは、プレイブックの再生が終了したときに呼び出されます。
• プレイブックの再生中に情報を受信するための HTTP コールバック。 Ansible タスクでは、アプリケーションへの POST/GET リクエストを実行します。

変数は、プレイブックの実行中に定義され、保存して以降の実行で使用する HTTP コールバックを介して渡されます。 このデータをsqliteで書き込みます。

また、コメントを残したり、HTTP コールバック経由でチケットのステータスを変更したりすることもできます。

HTTPコールバック

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

同じ種類の多くのタスクと同様に、Playbook 内で常に繰り返されないように、タスクを別の共通ファイルに置き、必要に応じてインクルードします。 これには、発行キーとホスト名を含む callback_ url が含まれます。 Ansible がこの POST リクエストを実行すると、ボットはそれが何らかのインシデントの一部として来たものであることを理解します。

以下は、MD デバイスからディスクを出力するプレイブックの例です。

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

このタスクは、Jira チケットを「変更準備完了」ステータスに転送し、コメントを追加します。 また、mdam_data 変数には、ディスクが削除された md デバイスのリストが保存され、parted_info には、parted からのパーティション ダンプが保存されます。

エンジニアが新しいディスクを挿入すると、これらの変数を使用してパーティション ダンプを復元したり、ディスクを取り外した md デバイスにディスクを挿入したりできます。

Ansible チェックモード

自動化をオンにするのは怖かったです。 したがって、すべてのプレイブックをモードで実行することにしました。
ドライランこの場合、Ansible はサーバー上でアクションを実行せず、エミュレートするだけです。

このような起動は別のコールバック モジュールを通じて実行され、プレイブックの実行結果はコメントとして Jira に保存されます。

まず、これによりボットとプレイブックの動作を検証できるようになりました。 第 XNUMX に、管理者のボットに対する信頼が高まりました。

検証に合格し、ドライラン モードだけでなく Ansible を実行できることがわかったとき、同じホスト上で同じ変数を使用して通常モードで同じプレイブックを起動するために、Jira に [Run Diskobot] ボタンを作成しました。

さらに、このボタンは、プレイブックがクラッシュした場合にプレイブックを再起動するために使用されます。

プレイブックの構造

Jira チケットのステータスに応じて、ボットはさまざまなプレイブックを起動することはすでに述べました。

まず、入り口を整理するのがはるかに簡単です。
第二に、場合によっては単に必要な場合もあります。

たとえば、システム ディスクを交換する場合は、まず展開システムに移動してタスクを作成する必要があります。正しく展開した後、サーバーに ssh 経由でアクセスできるようになり、そのサーバーにアプリケーションをロールアウトできるようになります。 これらすべてを XNUMX つの Playbook で実行した場合、ホストが利用できないため、Ansible はそれを完了できません。

サーバーのグループごとに Ansible ロールを使用します。 ここでは、プレイブックがその XNUMX つでどのように構成されているかを確認できます。

どのタスクがどこにあるかがすぐにわかるので便利です。 Ansible ロールの入力である main.yml には、チケットのステータスや全員に必要な一般的なタスク (ID の受け渡しやトークンの受信など) を簡単に含めることができます。

調査.yml

「調査」および「オープン」ステータスのチケットに対して実行します。 この Playbook で最も重要なのは、ブロック デバイス名です。 この情報は常に入手できるわけではありません。

これを取得するには、Zabbix トリガーからの最後の値である Jira 概要を分析します。 ブロック デバイスの名前 (ラッキー) が含まれる場合があります。 または、マウント ポイントが含まれている場合は、サーバーにアクセスして解析し、必要なディスクを計算する必要があります。 トリガーは、SCSI アドレスまたはその他の情報を送信することもできます。 しかし、手がかりがなく、分析しなければならないことも起こります。

ブロック デバイスの名前がわかったら、そこからディスクのタイプとサイズに関する情報を収集し、Jira のフィールドに入力します。 また、ベンダー、モデル、ファームウェア、ID、SMART に関する情報も削除し、これらすべてを Jira チケットのコメントに挿入します。 管理者とエンジニアは、このデータを検索する必要がなくなりました。 🙂

prepare2change.yml

ディスクを回転から外し、交換の準備をします。 最も難しくて重要なステージ。 ここで、アプリケーションを停止すべきではないときに停止できます。 または、十分なレプリカが存在しないディスクを取り外すと、ユーザーに影響が生じ、一部のデータが失われます。 ここではチャットでのチェックと通知が最も多くなります。

最も単純なケースでは、HW/MD RAID からディスクを削除することについて話します。

より複雑な状況 (ストレージ システム) では、バックアップがアプリケーション レベルで実行されるとき、API 経由でアプリケーションにアクセスし、ディスク出力を報告し、非アクティブ化してリカバリを開始する必要があります。

私たちは現在、大規模な移住を行っています。 雲サーバーがクラウドベースの場合、Diskobot はクラウド API を呼び出し、このミニオン (コンテナーを実行しているサーバー) で動作することを示し、「このミニオンからすべてのコンテナーを移行する」ように要求します。 同時にディスクのバックライトが点灯し、エンジニアはどのディスクを取り出す必要があるかをすぐに確認できます。

変更された.yml

ディスクを交換した後、まずその可用性を確認します。

エンジニアは常に新しいドライブを取り付けるわけではないため、満足できる SMART 値のチェックを追加しました。

どのような属性に注目しているのでしょうか?再割り当てされたセクター数 (5) < 100
現在保留中のセクター数 (107) == 0

ドライブがテストに合格しなかった場合は、エンジニアに再度交換するよう通知されます。 すべてが正常であれば、バックライトが消え、マーキングが適用され、ディスクが回転します。

準備完了.yml

最も単純なケース: HW/SW RAID 同期を確認するか、アプリケーションでのデータ同期を終了します。

アプリケーションAPI

ボットがアプリケーション API に頻繁にアクセスすることは何度か述べました。 もちろん、すべてのアプリケーションに必要なメソッドがあるわけではないため、変更する必要がありました。 私たちが使用する最も重要な方法は次のとおりです。

• 状態。 操作できるかどうかを理解するためのクラスターまたはディスクのステータス。
• 起動停止。 ディスクのアクティブ化/非アクティブ化。
• 移行/復元します。 交換時および交換後のデータ移行とリカバリ。

Ansible から学んだ教訓

私は Ansible が本当に大好きです。 しかし、さまざまなオープンソース プロジェクトを見て、人々がどのように Playbook を書いているかを見ると、少し怖くなることがよくあります。 when/ループの複雑な論理的織り交ぜ、シェル/コマンドの頻繁な使用による柔軟性と冪等性の欠如。

私たちは、Ansible の利点であるモジュール性を利用して、すべてを可能な限り単純化することにしました。 最上位レベルには Playbook があり、Ansible を少し知っている管理者やサードパーティ開発者であれば誰でも作成できます。

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

一部のロジックを Playbook に実装するのが難しい場合は、それを Ansible モジュールまたはフィルターに移動します。 スクリプトは Python またはその他の言語で作成できます。

簡単ですぐに書くことができます。 たとえば、上に例を示したディスク バックライト モジュールは 265 ラインで構成されています。

最下層には図書館があります。 このプロジェクトでは、対応するリクエストを実行するハードウェアおよびソフトウェア RAID を抽象化した別のアプリケーションを作成しました。

Ansible の最大の強みは、そのシンプルさと明確なプレイブックです。 これを使用する必要があり、恐ろしい yaml ファイルや膨大な数の条件、シェルコード、ループを生成しないようにする必要があると思います。

Ansible API の経験をもう一度繰り返したい場合は、次の XNUMX つの点に留意してください。

• Playbook_executor および Playbook には一般にタイムアウトを設定できません。 SSH セッションにはタイムアウトがありますが、Playbook にはタイムアウトがありません。 システムに存在しないディスクをアンマウントしようとすると、Playbook が無限に実行されるため、その起動を別のラッパーでラップし、タイムアウトで強制終了する必要がありました。
• Ansible はフォークされたプロセスで実行されるため、その API はスレッドセーフではありません。 すべての Playbook をシングルスレッドで実行します。

その結果、約80割のディスク交換を自動化することができました。 全体として、代替率は XNUMX 倍になりました。 現在、管理者はインシデントを見て、ディスクを変更する必要があるかどうかを判断し、ワンクリックするだけです。

しかし今、別の問題に直面し始めています。新しい管理者の中にはドライブの変更方法を知らない人もいます。 🙂

出所： habr.com