「ドメインサービス」ページのリニューアル第一歩！

当社は、ドメインとサーバーを提供するサービスであるが、
ここ数年間、新規のお客様の募集をしてこなかった。
ストックビジネスなので、既存のお客様からの安定収益があれば、
特に大きな投資等を行わない限り、何とかやっていけるからである。

でも今年は、サーバー代の仕入原価がものすごく高騰していたので、
さすがに値上げしないと利益を圧迫するようになってきた。

特に、ドメインについては、値上げと円安のダブルパンチで、
事業開始時の２倍以上に膨らんでしまった。
ドメインの種類によっては、既に赤字になっているものも出てきた。

というわけで、新規のお客様を募集するのにあたって、
ウェブサイトを作り替えることにした。

値上げについては・・・新規のお客様に適用すればよく、
既存のお客様は据え置きにしようと思う。
これは当社の創業時以来の変わらぬポリシーで、

新規の見込客にキャンペーン適用するよりも、
既存のお客様にキャンペーン適用するべきだ！

という凝り固まった考え方による。

それはさておき、サービスのリニューアルについては
ＡＩを通さずに、まず自分でいろいろと考えてみた。

３０年前の創業時とは時代が変わっていて、
今や高品質の大手サービスが乱立している時代なので、
当社のような零細企業は、同じ土俵で勝負しても仕方がないのだ。

ＡＩ（Gemini等）に、当社の強みについて尋ねてみると、
ホームページの文言を拾ってきて、
非セルフサービス型の個別対応サポートが得意、というような回答が出てくる。

電気屋さんに譬えてみれば、
全員が安さを求めて家電量販店やネット通販を選ぶとは限らず、
値段は高くても近所の街の電気屋さんで買う、という人も一定数いるのだから、
そういう人だけに絞り込めばよいことになる。

一般的に、ドメインとサーバーの業者を探す場合、
普通に探せば、つまり Google検索やＡＩのプロンプト入力で探せば、
大手の人気サービスが出てくる。

「自分で検索して探して比較検討できる」ということができる人は
大手の人気サービスを選ぶのが正解だけれども、
そういうことが苦手で「お任せしたい」という人も、いる。

そういう人向けのページを作らないといけないな、と思う。
とりあえず入り口の１ページ、ランディングページを作るのにあたって、
Geminiに相談してみた。

入力したプロンプト：

合資会社ユースマネージメントのドメインサービス事業部のホームページ
https://www.domainservice.jp/
を、新設の「ドメインサービス」という定番サービスのランディングページにしようと思います。
このサービスについて。
・ドメインを独立して管理するための１年間のサポート込みのサービス
・ＤＮＳまでは付いているが、ホスティングサービスは別。
・錦の御旗は「ドメイン独立宣言！」。旗の画像をバナーに使用。
・ドメインはサーバーのおまけではない、の主張。
・今こそ、ドメインだけを独立して管理しよう、という掛け声。
ランディングページのただき台をつくってみてください。

出てきた画像：

最初、誤字があったので何度か作り直しているが、これを少しだけアレンジして載せてみた。

ドメインサービス
https://domainservice.jp/
https://ドメインサービス.jp/

後は、少しずつ完成させていこうと思う。

サーバーを変更したら、フォームメール（ postmail.cgi ）のCGIが動かなくなった件

 サーバーマシンを新しいマシンへ変更すると、CGIやPHPのスクリプトが動かなくなるケースが多い。
特にCGIの場合、古いものを使っていることが多く、仕様が変わっていたりするケースもある。

さて今回、新しいマシンでフォームメールが「500 Internal Server Error」が出て動かなくなってしまう、という事象が出た。
このエラーだけだと詳細が分からないのでとりあえずログを見ると、

「End of script output before headers: postmail.cgi」

というエラーが出ていた。
何らかの理由でCGIスクリプトが異常終了した、ということなのだろうが、これでも原因が分からない。
こうなると、SSHでコンソールで、直接コマンドを入力して実行してみるしかない。

./postmail.cgi

と入力したら、

「Can't use 'defined(%hash)'   jcode.pl line 684」

というエラーメッセージが出てきた。
どうやら、postmail.cgi から呼び出される jcode.pl の684行目に問題があるらしい。

さっそく Google検索で、このエラーメッセージ
「Can't use 'defined(%hash)'   jcode.pl line 684」をそのまま入れてみると、

次のような答えた返ってきて、そのとおりに修正したら、見事にcgiが動作した。

従来のGoogle検索だけでも探せば答えにたどり着いたかもしれないけれども、
解決策がストレートに出てきたのは嬉しい。

以下、GoogleのAI回答：

Plesk Migratorでエラーが出て移行が開始できない！

Pleskで管理しているサーバーを新しいマシンへ移行する時、
新しいマシンもPleskならば、「Plesk Migrator」という機能を使って、
全自動で移行を行ってくれる。差分移行もできるので、とても便利だ。

本日、試しに１台、移行をやってみたら、最初にエラーが出て進まなかった。
ここ数年で、セキュリティ関連の制限が厳しくなったので、
古い方のマシンの場合、うまく動作しないことが多い。

今は、ＡＩという便利な相棒がいるので、さっそく活用してみることにする。

今までは、Googleにエラーメッセージをそのまま入れて検索したりしたけど、
今は、同じことをやっても、きちんとＡＩの回答が出てくるようになった。
この回答で十分なケースもあるけれども、より深い回答を得るためには、
やはり Gemini や Copilot の専用ページから入力した方が効率がよい。

さっそく入れてみたプロンプト：

plesk migrator実行後に次のエラーで失敗します。

Failed to fetch basic information about resellers, clients and domains data from source servers Cause: Command execution failed on the local server with non-zero exit code. command: rsync -r --chmod=Fu=r,Du=rwx,go= --timeout=30 -e 'ssh -i /usr/local/psa/var/modules/panel-migrator/sessions/20260703203631/ssh-keys/id_rsa.xxx.xxx.xxx.xxx -p 22 -o PasswordAuthentication=no -o StrictHostKeyChecking=no -o GSSAPIAuthentication=no' /usr/local/psa/admin/plib/modules/panel-migrator/backend/lib/python/parallels/plesk/source/legacy/extras/plesk_17_0_pmm_shared/ root@xxx.xxx.xx.xx:/root/plesk_migrator/plesk_migrator-7l9u3nzyui3jq8lnikx0b4zdfb2fbty1/pmm_agent exit code: 255 stdout: stderr: root@xxx.xxx.xxx.xxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(232) [sender=3.2.7] That is a critical error, migration was stopped.

以下、AIによる回答：

エラーログの提示をありがとうございます。原因がはっきりと特定できました。

発生している Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password) というエラーは、「移行先（Obsidian）から移行元（Onyx）へ、自動生成したSSH公開鍵を使って接続しようとしたが、移行元サーバーに拒否された」ことを意味しています。

Plesk Migratorは、最初にパスワードで接続が成功した後、高速なデータ転送（rsync）を行うために専用のSSH鍵を生成して移行元に配置しますが、その鍵認証の段階で弾かれています。

この問題は、以下の3つの対処法のいずれかで解決する可能性が非常に高いです。順番に確認・実行してみてください。

対処法1：移行元（Onyx）のディレクトリ権限（パーミッション）を修正する

移行元サーバー側の /root や .ssh ディレクトリの権限がセキュリティ的に緩すぎると、SSHの仕様により鍵認証が強制的に拒否されます（これが最も多い原因です）。

【手順】移行元（Onyx）サーバーにSSH（root）でログインし、以下を実行します。

Bash

# /root ディレクトリの権限を修正

chmod 750 /root

chown root:root /root

# .ssh ディレクトリの権限を修正

chmod 700 /root/.ssh

chown -R root:root /root/.ssh

# authorized_keys の権限を修正

chmod 600 /root/.ssh/authorized_keys

設定後、再度 Plesk Migrator を実行してみてください。

対処法2：移行先（Obsidian）で古い暗号方式（ssh-rsa）を許可する

Plesk Onyxが動いている古いOS（CentOS 7など）と、Plesk Obsidianが動いている最新OS（AlmaLinux 9やUbuntu 24.04など）では、安全なSSHの暗号方式の基準が異なります。最新OS側（移行先）のSSHクライアントが、古い暗号方式（ssh-rsa）を拒否しているケースです。

【手順】移行先（Obsidian：新しいサーバー）にSSHでログインし、以下を実行します。

1. /etc/ssh/ssh_config をテキストエディタで開きます。
2. ファイルの最末尾に以下の1行を追記して保存します。
   Plaintext
   PubkeyAcceptedAlgorithms +ssh-rsa

 (※OSのバージョンによっては PubkeyAcceptedKeyTypes +ssh-rsa の場合もありますが、まずは上記を試してください)

1. 保存後、移行先サーバーで再度 Plesk Migrator を実行します（クライアント側の設定なのでSSHの再起動は不要です）。

💡 おすすめの対応手順

まずは手軽かつ安全な 「対処法1（パーミッション変更）」 を試してください。それでも改善しない場合は、OSの世代ギャップが原因である可能性が高いため、 「対処法2（暗号方式の追加）」 を行うことで、多くのケースで解決します。

サーバー冗長化（二重化）の再検討と、新たな挑戦

インターネットのサーバー障害で非常に困ってしまうことは、
一般ユーザーの場合、

・メールが届かなくなる、または送信できなくなる
・WEBサイトが開かなくなる
・WEBサイトが更新できなくなる

ということになる。

ところが、WEB上で何かの業務サービス等のサイトを営んでいる場合、
長時間のサーバー障害は、ちょっとやそっと困ったというレベルではなく、
ダメージがケタ違いに大きくなる。

インターネットのサーバーは、
障害ゼロ、つまり稼働率１００％というのは、現実的には不可能であるが、
それでもなるべく稼働率１００％に近づけるために、さまざまなアイデアや工夫がある。

基本的な手法として「冗長化（じょうちょうか）」というのがあり、
障害にそなえてあらかじめ予備を作って二重化しておく、という考え方である。

当社のサーバーは、安くもなく高くもないフツーなレベルだと思うけど、
今回の大障害を大反省して、トライ＆エラーを繰り返しながらも、
絶対に安全で信頼できるサービスを提供していきたい。

当社の強みは、この３０年間に築いた、苦難に満ちた実体験、の存在である。
お金をそれほどかけなくても、独自のアイデアでサーバー冗長化を実現する知恵は、十分にある。

実は、過去にも、同じことを考えてやっていたことがあったが、
なぜ今、止めてしまって、また同じ大障害を繰り返してしまったのか？
という反省をしなければならない。

サーバーを二重化して障害を防ぐためには、両方のサーバーの状態が
常に最新状態になっていなければならないと、障害時に役立たない。
簡単なようで、それができていなかったのだ。

お客様も、最初は、障害に備えて、両方のサーバーを最新にしてくれているが、
障害が全くなく何年も安定稼働が続くと、そんなことは忘れてしまう。

当社側も、ＧＭＯ社の「クラウドＶＰＳ」は、もう何年も障害がなく、
安心しきっていたので、肝心の予備サーバーが放ったらかしになっていて
いざという時にあまり役に立たなかった、という失策があった。

古いサーバーのままになっていたので、

・ＳＭＴＰサーバーが SPFとDKIMに対応できていない
・Let's Encryptの更新ができないのでＳＳＬ接続ができない

等の問題が露呈した。
これらがきちんと機能していれば、予備サーバーとしてきちんと機能していたはず、である

なので今回、暫定対応できたのは、

・メール転送機能
・障害のお知らせ（お詫び）ページの掲載（ただしＳＳＬ無し）

だけだった。

ということで、今回は、きちんと代替えできる予備サーバーを整備して、
本当の二重化に挑戦しようと思う。

技術的な話をすると、
メールサーバーについては、ＤＮＳのＭＸレコードを２つ入れておけば二重化ができるが、
ＷＷＷサーバーについては、少し工夫が必要になる。
ＤＮＳにＡレコードまたはＣＮレコードを２つ入れておくと
ラウンドロビン（交互に接続）になってしまうので、それはうまくない。

今回契約した ClouDNS というＤＮＳサーバーを使うと、
IPフェイルオーバーという機能で、障害時に切り替えることができるらしい。

無停止を希望するお客様には、これを選択できるようにすればよいが、
その代わり、２つのサーバーの内容を最新に保つ運用が必要になる。
障害時は暫定ページを表示されればよい、というお客様もいると思う。

とにかく、メールとＷＥＢがなんとかして二重化できていれば、
サーバー障害が起きてもそれほど困らないので、
ワクワクするようなサービスを安心して使えるはず、である。

この独自性のある仕組みを、これからの標準装備としようと思う。

「サーバーが落ちても、困らないサービス」を目指そう！

今回のサーバー障害の直接的な原因は、どうやらシステムファイルの破損？だったらしい。
ＧＭＯクラウド社側で、サーバー起動時のエラーログを分析して、
ベンダーの回答待ちだったために、土・日は何もできずに週明けにならない対応できません！
ということだったらしい。

結局、月曜日になっても復旧目途の連絡は来なかったが、きちんと対応してくれていたらしく、
夜になって復旧していたことが確認できた。
次の日になって、以下の連絡をいただいた。

  + 
  + VPSサーバー内に設置されていたライブラリ（lib）ファイル、およびそのシンボリックリンクの影響により、
  + VPSが起動できない状態となっておりました。
  + 
  + そのため、該当のファイルおよびシンボリックリンクへの対処を行いましたところ、
  + 正常に起動可能な状態となりました。
  + 原因となったファイルにつきましては、一時的にVPSの「/root」配下へ移動いたしております。
  + 
  + 対象ファイル : /root/ld-linux.so.2
  + 

サーバーは起動したけれども、Plesk側でシステムエラーを吐いていたので、すぐには回復しなかった。
障害になる直前、Pleskのアップデート失敗のログも出ていたので、Pleskのシステムも破損していたらしい。
Pleskは自動修復機能も充実しているので、サーバーコンポーネントの[更新] 等をやったら、回復した。

それにしても、数日間にわたるサーバーの停止というのは、とてもダメージが大きい。
一時的な障害とは違って、受信メールもエラー返送されてしまうので、心象も悪くなるだろう。

システムファイルの破損が原因でサーバーが起動しないトラブルは、
２０年くらい前にも一度経験しているが、
今回のようにマシン本体が起動しないと、どうにも対処できないので辛い。

Raq550サーバーで cce が起動しない問題が解決！
https://shunichi.hosono.com/?p=133

サーバー障害をゼロにすることを目指すのは当然ではあるが、
想定外の事態が起きて、やむなく障害になってしまうケースも、残念ながら、ある。

「想定外もあり得る」ということを否定していたら、現実的な対応はできない。

今後は、
「サーバーが落ちても、困らないサービス」を最優先にしようと思う。

そのヒントは、
「サーバーが落ちていたのに、このブログはなぜ生きていたのか？」というところにある。

サーバーが物理的にダウンして、ＷＥＢもメールも何にも機能しなくなっても、
ＤＮＳだけは冗長化されているので、別のサーバーでサービスを継続することができるのだ。

このブログは、Google社のBloggerというサービスを利用しているので影響を受けなかった。
外部サービスとうまく連携しながら、ＤＮＳの冗長性を生かして、

サーバー障害が起きても、慌てず騒がず、安心して使えるサービスを提供しようと思う。

週明け（月曜日）になったが・・・

週明け（月曜日）になって、ＧＭＯ社から朝一番で連絡をいただいた。

+
+ この度はご不便をおかけし、申し訳ございません。
+ 本件につきましては、現在も弊社の担当部署にて確認を進めておりますが、
+ 復旧見込みのご案内が難しい状況でございます。
+
+ 確認ができ次第、あらためてご案内いたします。
+ お待たせしているところたいへん恐縮ではございますが、お時間をいただくこと、
+ 何とぞご理解くださいますようお願い申し上げます。

+ 

このメールの返信で、
有償プレミアムサポート（月額11,000円）に今すぐに申し込むから
当日中に修復してほしい、という旨を伝えている。

もしかするとＧＭＯクラウド社は、有償プレミアムサポートに申し込まないと
「塩対応される」ことになっているのかもしれないからだ。

でも夕方に帰ってきた次の回答は、こうだった。

+
+ この度はご不便をおかけし、申し訳ございません。
+ 現在、先週の6/19よりベンダーへ確認を行っておりますが、
+ 詳細の確認に時間を要している状況でございます。
+
+ 大変お待たせしているなか、明確な進捗をお伝えできず大変心苦しい限りではございますが、
+ 何卒ご容赦いただけますようお願い申し上げます。
+
+ お急ぎのところ誠に恐れ入りますが、新たな情報が分かり次第、
+ 改めてご連絡いたしますので、今しばらくお待ち
+ くださいますようお願い申し上げます。
+ 

こんな調子なので、当日中の回復見込みは絶望的だと悟り、
「（３）月曜日に、復旧目途が全く立たない場合」
のシナリオを準備することになった。

まず、暫定対応で使用しているサーバーは、ＯＳも管理画面（plesk）も
バージョンが非常に古いので、これに代わるサーバーを見つけることから始めた。

サーバー業者の探し方について、ＡＩ検索をいくつか活用してみたが、
Copilot が最も賢い分析で、適切なサービスを見つけてくれた。

実際に今日、申し込んだのは、Contaboという会社のＶＰＳサーバーである。
条件は、Plesk対応で、日本語サイトも問題なく使えること、くらいである。
私はこのサーバー業者は知らなかったが、２０年以上の老舗で、ドイツの会社だった。
最近、日本国内リージョンを設けたので、安くて高品質なサーバーとして人気上昇中（？）らしい。

予備サーバーとして使用するならば、最も安価なサーバープランで問題ないが、
Pleskを利用するとなると、月額5,000は超えてしまう。でも仕方がない。
こういう緊急用途に、いつでも利用できる体制にしておくと安心だから、だ。

そうして、準備を進めていたなか、２０時くらいになって、
今回障害中で起動しなかったサーバーが、起動されているのを確認した。

ＧＭＯクラウド社側からは特に連絡は入っていないが、起動だけしてくれたのだと思う。
さっそくPleskにログインしてみると「ライセンスキーが無効」エラーは解消されていたが、
操作をしてみると、メール設定の画面でシステムエラーが出たりして、安定しない。

あくまでも推測だが、6月19日(金)の朝２時頃、通信障害が起きたことで
Pleskのアップデート処理が途中で失敗し、システムが一部壊れたのかもしれない。

これについては、Geminiに、こう尋ねてみた。

以下、プロンプト

Pleskのメール設定で「ERROR: Error: Call to a member function isDovecot() on null (EmailAddressController.php:329)」エラー画面が表示されてしまいます。

すると、解決するためのコマンド例や操作方法が表示されたので、
それをいくつか実行したら、自動修復されたようだ。

さっそく、暫定サーバー側のＤＮＳを、プライマリからセカンダリへ切り替えて、
元のサーバーへ切り戻した。

とりあえず、一旦はこれで仮回復ということになるが、
何か隠れた不具合があるかもしれないので、要注意だ。

今回の大障害の反省と教訓を、次のより良いサービスへ昇華していくことが必要なので、
今回申し込んだ新たなサーバー「Contabo」も活用していこうと思う。

当社のコンセプト「ドメインを中心に活用する」は、障害対策の切り札になるだろう。

障害分析と反省点

今回のサーバー障害（2026/6/19～）について、
原因分析と反省点を考えてみようと思う。

●障害の発見について

まず、障害の発見は、リアルタイムでの発見はできなかったものの、
早い段階で発見して、ＧＭＯクラウド社への連絡はできていたと思う。

朝のメールもきちんと届いているしＷＥＢサイトも閲覧できる状態で、
サーバーの各種サービスの停止を知らせるアラートも受け取っていないが、
受信メールがいつもよりも少ないことで、異変に気付いた。

特に「毎日大量に届く迷惑メールの数が少ない」というのは異常だった。
ここで、朝２時くらいから後のメールが来ていないので、おかしいな？と気づいた。

さっそく、サーバーの管理画面（Plesk）にログインしてみると、
「ライセンスキーが無効です」というエラーメッセージが表示されて、
一切の操作ができない状態になっていた。トップ画面すら開かない。

このエラーは通常、Plesk社へのライセンス料が未支払いのために起こるものだが、
サーバー料はきちんと支払っているし前日も問題なく利用できていたので、
何か別な理由で起きている問題だとすぐに判断できた。

実はこのエラーは、2021年12月に、旧サーバーの時に経験しているので、
Pleskのライセンスサーバーへの通信が一時的に失敗したのだろう、とすぐに解った。

●障害の原因調査について

朝９時に、ＧＭＯクラウドの技術問い合わせで、障害調査と回復を依頼した。
ＧＭＯクラウド社の障害・メンテナンス情報を見てみると、この日は
朝２時から「ネットワーク機器メンテナンス」が行われていたことが確認できた。

【メンテナンス予定/GMO CLOUD】ネットワーク機器メンテナンスのお知らせ
https://support.gmocloud.com/info/detail.html?no=91503

これは計画メンテナンスだったはずなので、お知らせが来ていたはずなのに、
受け取り損ねたか、スパムメールに入ってしまったのか、確認ができていない。
が、

「ネットワーク機器は冗長化されているため、基本的に通信影響はございません」

となっていたので、影響はないはず、なのだが、
メール機能が停止した時間帯とちょうどぴったり重なるので、怪しいと感じている。

朝８時になってもメール機能に不具合が出ていた状況で、
メンテナンスが朝６時には終了していたのに、
ホームページでの掲載がまだ「作業前」「メンテナンス予定」のまま、
であるのは何か不自然ではないか？　と考えていたところ、

９時以降になって、次のような障害情報が発表されていた。
ここに記載の対象IPアドレスが当社のものと一致していた。

【発生・復旧/GMO CLOUD/ALTUS byGMO Basic】ネットワーク機器の障害につきまして
https://support.gmocloud.com/info/detail.html?no=91776

さらに、
午後になってから気づいたのだが、新たな障害情報が掲載されていたのを確認した。

【発生・復旧/GMO CLOUD/旧ラピッドサイトVPS】障害発生のお知らせ
https://support.gmocloud.com/info/detail.html?no=91784

対象IPアドレスは明確な記載がなかったが、
「外部ネットワークへの疎通不可の状況が発生しておりました」という記載から、
WEB閲覧は問題ないのに、メール機能とFTPに不具合が出て、
さらにPleskのライセンスサーバーとの通信できない、
という症状に一致するのでは？　と疑ってみた。

その後、この障害情報は、「障害発生・復旧時間」が訂正されていた。
もしこの障害が当社サーバーの事象と関係しているならば、
13:53 まで放置していたら自然に全回復された、となったかもしれない。

後から考えれば、
13:00 にサーバー再起動を試みたのが失策だった！という結果になるが、
その時点でサポートからの連絡も皆無だったし、
その時点ではこの障害情報が掲載されていなかったので、
「13:53まで待ってみよう」という呑気な判断をすることは、あり得ない。

とにかく、13:00 の時点では、ＧＭＯクラウド社からの障害情報は確認できず、
自サーバー側の問題をまず疑ってみるということで、
その時点での現状分析は間違ってはいなかったと確信している。

■サーバー再起動の判断について

でも、サーバーを再起動する前に、もう少し慎重に、
コンソールへログインしてもう少し詳細情報を確認してから実行すべきだったのでは？
という反省点もあるが、
そもそもリモートログインすら繋がらない状態だっただろうし、
経験上、まずサーバー再起動を試してみることが最も手っ取り早い解決策だったので、
サーバー再起動の判断自体は、間違いではなかったと考えている。

問題は、
慣れない Virtuozzo PowerPanel で再起動したこと、である。
いつもやっている Plesk管理画面ならば「再起動」を選択するのだが、
今回は操作ができない状態になっているので、それができない。

Virtuozzo PowerPanelには「再起動 または Restart」ボタンがなく、
「Start」「Stop」「Reset」の３つボタンしかなかった。

通常、仮想サーバーで仮想マシンを通常再起動する場合は、
「再起動 または Restart」ボタンを選択するのが常識で、
「Reset」ボタンとは、ハードリセットつまり「強制的な電源オフ・オン」を意味するので
緊急時以外は使っちゃいけないもの、という思い込みがあった。
ハードリセットを行うと、ファイルが破損したりして起動しないリスクがあるからである。

なので今回は、
「Stop」ボタンを押した後に「Start」を押す、という安全な方法で、再起動を行った。
「Stop」が成功したので「Start」を押した、つもりだったが、
起動中に「PRL_ERR_VTCTL_OPPERATION_FAILED」エラーが出て、起動ができなかった。

その後、何度か起動を試したが、毎回同じエラーが出て、起動ができなくなってしまった。

こうなると、サーバー全体が停止してしまうので、今まで動作していたＷＥＢサービスも
Plesk画面も、何もかもが利用できない状態になってしまったので、最悪な状態である。

このことは結果論として、
「あの時、このサーバー再起動をやっていなかったら、最悪の状態は免れたのだ！」
と非難され続けることになるのかもしれない。

が、上述のとおり、この時点での再起動の判断は間違っていなかったと確信する。
エラーが出て起動できなくても「適切に対処」すれば必ず起動できるようになるからである。

想定外だったのは、
「起動時にエラーが出て起動できなかったこと」自体ではなく、
「ＧＭＯクラウド社側が、対処してくれないで週明けまで待たされること」だった。

（つづく）