先週末に自社コーポレートサイトの全面リニューアル＆サーバー移動を行いました。今回はドメインはまったく変更が無いので、なくなるページの301転送を行ったりはするものの、対して面倒なことは起きないと思っていたら…リリース直前に大変な目にあったので、備忘録に残しておきます。
ステージング環境で問題なく動いていたのに、本番環境ではiPhone（iOS）だけ真っ白でコンテンツが表示されなかったり、CSSの読み込みがされず表示が崩れていました。
Contents
iOS・Mac OSだけの不具合
今回のリニューアルは
- デザインとコンテンツの100%リニューアル
- 新しくステージング環境を用意する（本番と別サーバーのAWSを使用。設定は同じ）
- 本番環境も移動（すでに動いている別のWebサイトが入っている）
- WordPressを使用する
- ドメイン変更なし（https://も含めて）
というものでした。
ですので、ステージングで確認を完了し、制作会社が本番環境にデータをコピー、DNSを切り替えた途端、iPhone（iOS11とiOS12）で真っ白になったり、表示はされるもののCSSがあたっていなかったり、きちんと表示されてもページ移動をしているうちにCSSや画像の読み込みがされないページが増えて行ったりとしたときは、頭も真っ白になりました。
テスト環境と本番環境の違い
テスト環境できちんと動いていたので、まずはテスト環境と本番環境の違いを調査しました。制作会社にはWordPressの設定を、自社情シスにはサーバー状況（本番とステージングで設定が違うのでは？）の調査を依頼。
制作会社からは「WordPressではないので、以下を調査して欲しい」との連絡がありました。
- ロードバランサーの設定は問題がないか
- AWSでのHTTPSのConfig設定は問題ないか
- IP変更による設定は問題ないか
弊社情シスからは「確認しなおした。問題は無い」との返事。
気持ち悪いのは、段々と見える頻度が上がってくるなど、何も対応していないのに状況が変化することでした。
目に見えてわかる違いは、ステージング環境のドメインにもHTTPSが使えるようにしていたにも関わらずHTTPで制作されており、本番環境はHTTPSだということです。そこから、「AWSにおけるWordPressとHTTPS使用時の不具合」ということで、以下のブログに辿り着きました。
[AWS] AWS 上の WordPress が HTTPS で正常に表示されない場合の対処
HTTPS化できるのに（一瞬HTTPSであった気がする）HTTPで作られていることから、制作会社がHTTPSで構築し始めたら動かなかったので使うのをあきらめたのではないかと思います。
実際、テスト環境をHTTPS化したところ、本番と同じような状態になるのが確認されました。以降はステージング環境で色々と確認＆テストを繰り返します。
The operation couldn’t be completed～プロトコルエラーの表示
エラーメッセージを調べると、HTTP2の設定に関係があるかもしれないとのことです。
https://community.cloudflare.com/t/ssl-causing-website-to-not-load-at-all/39764/21HTTP2の設定を有効にすれば解決するかもとのことですが、いかがでしょうか？
https://knowledge.sakura.ad.jp/7735/
早速色々調べましたが解決せず…が、これが大きなヒントに。
Upgrade header を送らないようにするだけ
HTTP2の話題が出てきたことで、検索キーワードが一つ増えました。
結局、以下の記事が決め手となり、AWSのHTTP/2 という項目を無効にすることで、ステージング環境でiPhoneやiPodで表示されることが確認できました。
iOS 11, macOS Hight Sierra で The operation couldn’t be completed. Protocol error が出る場合の対処
今回の反省と今後の注意点
今回のことはサーバーの知識も無く触ってもいない私自身には事前に対応はできなかった事態ですが、もっと早く異常があることに気づくことができたきっかけは幾らでもありました。
コーポレートサイトとWordPressという個人的には作りなれた状況であるため、重い不具合などを想定することができなかったのもあります。
今後は以下の反省点を活かしたいと思います。
テスト環境がHTTPで動いると気づいた時点でチェック
- 制作会社は確認せずに「使えない」と判断せず、質問すべきだった
- 「HTTPSを何故使わないのか」と疑問を口に出すべきだった
これに尽きます。
もちろん不具合が無いのが一番ですが、不具合を見つけるには小さいことでも疑問を残さないことが大事だと思います。少なくとも、これが出来ていれば、本番移行前に課題を見つけることができました。
サーバーの設定の責任範囲の明確化
- 「サーバーしか考えられない」となった時点で「サーバー設定は別料金」と制作会社に言われたが、どちらがどこまでやるかが不明瞭だった
- 弊社側では、WordPressを使用した別のサイトが本番で動いているので、特に特別な設定をする認識が無かった
- お互いが「確認しつくした。こちらには問題はない」という認識に早い段階で至ってしまっていた
- 「WordPressをインストールするのは制作会社だから」と細かい確認作業を行わなかった（恐らく、制作会社からすれば「事前にWordPressを使うと言ってあるのだから、ちゃんと対応してよ」と思っているはず）
セキュリティの問題があったので、サーバーの深いところは触れない状態で制作会社に渡していました。既に動いているWebサイトの構築はサイトを制作した別会社がしたらしいので、サーバーに対するナレッジや準備が不足していたと言えます。
それでも今回はDNSの切り替えがあったため情シスが待機していましたが、それが無かったら社内に解る人が残っていなかったかも。次からはある程度大きな変更時には情シスの稼働も確保しないと…と思いました。
また、社内にある程度分かる人がいることで、責任範囲が曖昧だったことも大きな反省点です。
動作確認環境が不明瞭？
- 制作会社側の確認スマホが、当初Androidだけだった
- そのためこちらから「おかしい」と伝えても「おかしくない」という返事で初動が遅れた
- お互いが「確認しつくした。こちらには問題はない」という認識に早い段階で至ってしまっていた
RFP（Request for Proposal）の中で「弊社ガイドラインの推奨環境の適応」とは謳っているのですが、具体的に制作会社がどの端末で確認しているかなどはチェックしていませんでした（そこまで言わないといけないのかと思わなくもないですが）。
実際、「スマホの動作確認」をパソコンのブラウザ（エミュレーター）で済ましてしまう制作会社もあるので、「実機でする」ことと、「どの実機でするのか」はリスト化してもらうべきだと思います。