不具合で身の潔白を証明できず1日半を潰した話

クライアントさんから「作業前と比べて不具合が出ている」と連絡を受け血眼で原因究明したものの、結局Chromeのアップデートが原因で1.5日を無駄にしたという何とも悲しい経験をしたので、同じ轍を踏まないために今回の反省点やポイントについてまとめておきます。

トラブルの経緯

今回の不具合は「Chromeブラウザだけでフォーム周りのJavaScriptによる挙動がおかしい」というものでした。もともと2週間前にサイトの改善のご依頼を受けて実施したものの、そもそもの構造的に改善が難しいことが分かり、前入金の一部を返金する手続きの途中の状態でした。

不具合の連絡を受けた時、手元のパソコンで再現を確認したもののChromeのデベロッパーツールのConsoleを見ても何が原因かはすぐには分かりませんでした。また作業から数日経っており記憶が薄れていることもあったと思います。

1番の原因は元に戻せなかったこと

原因が不明なので元の状態に戻そうとしましたが、それがやりにくい原因がいくつかあり、今回の「不具合が自分のせいじゃ無いと言い切れない」という状況を招いてしまったのだと思います。

完全なバックアップを取っていなかった

今回、Amazon EC2 という初めてのサーバー環境で、SFTPによる接続までは出来たもののサイトのデータ量があまりにも膨大（FileZillaで1時間かけても作業キューに追加する作業すら終わらない）で、一部のファイルしかバックアップを取りませんでした。

AWSコンソール側でバックアップはおそらく取れるのですが、今回はコンソールへのアクセス権は要求せずFTP情報とSSH用のPPKファイルしか貰っていませんでした。

後になって見返すと触ったフォルダなのにバックアップを取っていないファイルが多数あり、作業前に完全に戻すことがそもそも手元のデータだけでは出来ない状態でした。

大容量データのバックアップの難しさ

そもそも毎回バックアップは取るのですが、今回それを怠った原因としてバックアップしたいサーバー上のデータが大容量すぎて、時間的にも僕のパソコンの容量的にも「こんなの全部バックアップ取ってらんないよ！」という状態だったから取らなかったのです。

おそらく10GBはあったのではと思いますが、SFTPでの接続だったからFileZillaでの転送速度が遅かった可能性もあります。

こういったクライアントワーク時のお客さんの大容量サーバーデータの良いバックアップ方法がググっても出なかったので、もし良い方法があれば教えて欲しいです。

それでもバックアップは取れ

バックアップに時間がかかるからというのは結局「めんどくさい」という言い訳なので、まず作業前にサーバー内の構造を見極めて今回編集するファイル群はこれだというのを把握してから、少なくともその触る可能性がある画像以外のファイルはバックアップしておくべきでした。

jQueryのバックアップが本当に作業前のものか怪しかった

今回フォーム周りの制御を中心にjQueryを多用している構造のようで、サーバー上のjquery-3.3.1.min.jsファイルをヘッダで読み込んでいる形でした。しかしこのバックアップを取った時にbeautifyするためかでjQueryのサイトのv3.3.1のものをコピーしたり上書きしたような記憶があったのです（つまり「このサイトではサーバー上のファイルから読み込んでいるけど中身は同じjQueryだからサイトから持ってきても同じでしょ」と安易に考えた可能性があったのです…）。

ここ最近、Google Chrome でaddEventListenerで付与されるpassiveというプロパティがデフォルトでtrueになっており、jQueryの原文のままではChrome Console に警告が出るだけでなく実際にサイトに不具合が出たりしたのです。

今回の不具合が出たサイトにもConsoleに同様の不具合が出たため、「もともとのサーバー上のjquery-3.3.1.min.jsは上記の対策をしたものだったのでは？」「それを原文のコードで上書きしたから不具合が出てるのでは？」という不安があり、かつそれを元に戻せないため、自分のせいでは無いという言い切りができませんでした…。

お客さんが作業後にファイルを触ってた

ちょっとズレますが、今回お客さんが僕の作業後に新たにHTMLに結構な編集を加えていました。にもかかわらず（非エンジニアでは仕方ないかもですが）サーバー上のファイルを直接編集したそうで、僕はそれを持っているファイルで上書きしてしまいました。

結局はお客さんの手元に最新のファイルが残っていたのですが、gitによるバージョン管理もしておらず、バックエンド側もGitHubなどのクラウドサービスは利用されていませんでした（個人のパソコン上のgit利用のみ）。

検収期間中（といっても明確に日数を定めてなかった）に不具合の連絡がきたので、てっきり「僕が作業した後の状態のまま確認する時間がなくて放置してたのかな」と解釈してしまっていましたが実際は追加ファイルを触っていました。

何となく嫌な予感がなかった訳ではないものの、結局「お客さんって自ら無償修正してもらえる可能性を下げたり、支払いが発生するような面倒なことは進んでやってくれないんだ」ということを再認識させられました。

すごく不誠実を感じてお客さんに文句を言いたくなりますが、結局は自分も含めて人間であり、経営の鉄則は「回収は早く、支払いは遅く」なので、僕もこの鉄則に則って早く回収を迫るべきでした。

なんかとても悲しい気持ちになります。

サーバーの設定ファイルをVimで直接編集した

後述しますが今回はNginxを利用しており、etc/nginx/nginx.confのような設定ファイル群がいくつかあります。パーミッションの関係かこれらのファイルだけはSFTP接続しているFileZilla経由では上書きができず、またパーミッションを変更しても負荷なのでMacのターミナルからSSH接続語にsudo vim nginx.confのコマンドを叩いてVimで直接ファイルをいじりました。

しかしそのせいで元の環境に戻す時に「またターミナルでSSH接続してVimで編集しなきゃいけない」という億劫さがあり、元の状態に戻すことへの障害のひとつとなってしまいました。

Amazon EC2 (AWS) を甘く見ていた

今回、Amazon EC2 + Nginx + Ubuntu という環境で正直どれもがほぼ初めて触る環境でした。

「触ったことないから出来ません」なんて言ってたら仕事なんて出来ないので当然調べながらXSERVERやApacheとの違いを探っていく訳ですが、流石に未知の領域が深すぎて無謀だったかなと反省しています。

AWSやNginxは結構前から定番になっているはずなので、やはりAWS勉強会に参加したり、サーバー周りに詳しいエンジニアの友達を作って、定期的にもくもく会などで交流する必要性を感じました。

またFileZillaやSourcetreeなどのGUIツールばかりに頼ってCLI（ターミナル）でのコマンド操作を結構避けてきました。しかしSSHを始めまだまだコマンドでないと出来ないことが多いと感じ、今後はなるべくコマンド操作を覚えていこうと思います。

Nginxコマンド

ちなみにNginxも今回が初めてだったので使ったコマンド一覧をメモしておきます。

まずWindows用のSSHキーである.ppkファイルをもらったので、これをMac用の.pemファイルに変換する必要があります。この変換はググったら変換ソフトなどが出てきます。

SSH接続

それをユーザーのルートドメイン配下の.sshディレクトリに配置して以下コマンドを叩くとSSH接続できます。

 ssh -i ~/.ssh/sample.pem [ユーザー名]@[IPアドレス]

Amazon EC2 ならユーザー名は基本ec2-userになるのですが、今回はOSがUbuntuだったためか違いました。

Super User 権限でファイルを編集

sudo vim nginx.conf

Nginxの再起動

sudo service nginx restart

他の記述方法も色々あるみたいです。今回Ubuntuだったから上記だったのかも。

デバッグ力のなさ

サーバーサイドの話から一転して今度はフロントエンドの話ですが、主にChrome Developer Tools を利用したデバッグ術の弱さを改めて感じました。

一般的なElementsタブの利用やCSSのリアルタイム編集、Networkタブで読み込みファイルや読み込みスピードを把握したりくらいは出来ていました。Coverageタブで使用されていないCSSを割り出すとかも出来ます。

しかしブレークポイントの貼り方のコツや Event Listeners の項目の利用法などが弱く、つまるところJavaScriptをちゃんと体系的に理解できていないです。

jQueryないの記述を読んでも関数とメソッドの違いや、「そもそもEvent Listener って何だ？」という状態だったのでデベロッパーツールを見てもそれを使いこなすための知識が不足している感じでした。

熟練のエンジニアならこのツールを駆使して今回の原因や、少なくとも今回触った箇所が原因でないなどを特定できそうですが、うまく出来ずでした。

Webの情報を漁りながらの付け焼き刃の知識の限界を感じます。本で体系的な知識をつけるか、やはり会社などで先輩から教えてもらうのが一番ですね。はぁ、会社での人間関係のストレスが無い人っているんだろうか。

フリーランスとしての心得？

心得として言い切れるかまだ微妙なので、疑問形でメモしておく。

• 検収期間って設定した方がいいのかな
• 固定IPな方がアクセス制限やGAの除外などに都合が良い
• GitHubのPrivate Repositoryに招待してもらい納品はPull Requestという納品形態が一番良いのかも