2020年12月15日記載
システム開発のスクラッチ案件は安価で受けてはならない
PHP8を導入してから徐々にいろんなことがわかってきた。先週金曜日から昨日にかけて今動かしているサーバの動きが突然遅くなる事象が頻発した。状況を調査したところサーバCPUが100%で稼働し、メモリもパンパンに消費する異常事態に陥っていた。PHP8に切り替えてからのタイミングと一致したのでPHP8が原因ではないかと疑った。

しかたがなくPHP7.4に一時的に戻して様子を見ることにした。ところが昨日再び同じような現象に見舞われた。Apacheを再起動するとメモリもCPUも元に戻るが、数分したら再びフリーズする事象の繰り返し。Webアクセスがまともに動作しない状況が頻発したた。

別にで管理するサーバもPHP8に切り替えて運用しているが、こちらは本サーバのような事象は一切発生せず安定運用中のままだった。

そうなるとPHP8の問題はないと判断。そこで1ヶ月で辞めたWordPressファイルが私の知らないところでバックエンドで動いて悪さをしている可能性を疑った。速攻でWordPress関連ファイルをごっそり削除を行った。

それでも虚しく数分後に同じようにサーバはフリーズしてしまった。

頻発するフリーズによってWebサービス運営に影響を及ぼし頭を抱えていた。しばらくサーバ稼働状態をモニタリング中にサーバのメモリ消費が急激に悪化する状況をリアルタイムで観察することができた。

「何なん?これ?」

慌ててWebサービスのアクセスログをチェックした。するとWebサービスに利用者登録している、特定のユーザのアクセスタイミングと一致していたことが判明。詳細原因は不明だが、やむなく該当ユーザの利用を強制停止の措置を発動した。

強制停止発動してからトラブルはピタっと止まった。この文章を書いている今の段階も昨日のようなトラブルは一切発生していない。

現時点での推測では、ユーザのある操作をするとサーバの動作がパンクする要因を作っていたのではないかと推測している段階である。

Webサービスを提供する場合、ユーザがどんな使い方をされてもサービスが止まらないように設計する必要がある。

それができていなかったということだろう。不特定多数のユーザに提供するサービスは、いかなる操作であってもシステムが止まらないように設計して作らなければならない。要するにユーザの行動はすべて疑って作るのが鉄則である。サービス設計において必須の考え方である。これができていなかったのである。

ところで、PHP8はPHP7.4では見過ごされてきた小さなプログラミングミスも指摘するように厳格化された印象がある。

PHP8にアップグレードしてから発生した新たなエラーは、いずれも私の書き方の問題が原因だった。PHP8特有の問題ではなく、PHP7.4ではエラーを表示せずにスルーで動いてくれていただけであった。

サービスを開始してから丸2年が経過したが、未だにサービス開始当初に書いたソースが原因による動作不具合が適時発覚している。

いずれもユーザからの問い合わせにより、バグが発見されている。デバッグは自分だけの確認では事前に100%発見することは困難である。運用しながらユーザから指摘され、都度お詫びしながらデバッグを繰り返す。結果的により堅牢なシステムに発展させていく。

あのGoogleですらシステムトラブルを発生させるぐらいである。もちろんプログラミングのレベルが根本的に異なるので同一次元で語るのはおこがましいが、一人でも多くの利用者が、ソフトウェアとは機能が増えれば増えるほど、見過ごされているバグが潜在的に内包されるリスクが高くなることを知って欲しい。

最初から100%撲滅させるのは困難な世界である。とはいえ、世間は有料サービスではバグを許さない厳しい世界だ。

以前安易安価で引き受けた受託開発案件があった。先日発注者とトラブルに発展した。内容はバグ問題や要件定義内容との認識の違いが主たる原因だった。

発注者は簡単に考えている機能追加のつもりだが、請け負う立場にとって追加要望に応えるには明確に人的コストがかかるレベルの内容だった。そのためしかるべき追加費用が発生する旨をお伝えし、追加見積もりを提出したら逆ギレされてしまった。

これまで労力をかけてゼロから作ったのに、追加改善に対し追加費用を提示したら「白紙を含めて検討さえてもらいます」と言われる始末。

もともとシステム開発には疎い発注者なので、バグ発生の認識や機能改善には、常にコストかかる認識をもっていないことを改めて思い知らされた。

受託案件では発注者の思いと請負側の思いが完璧に一致することは少ない。だからこそ、受託案件を請け負う場合は、これらのリスクもはじめからすべて費用に盛り込んで見積もり提示しておく必要がある。

安価で受けていなかったらこんな思いはなかった。安価で請け負ったため、費用にそぐわない要望は追加見積もりを提示せざるを得なくなる。

しかし追加請求される側からしたら気分は悪く思うのは理解できる。つまり最初に安価で提示した時点で私の失敗だったということである。

今回は痛い勉強代になった。もう安価な受託案件受注は一切やらない。もしそれでも受託請負するなら、リスク分の稼働を含め部分外注しても耐えられる元請単価でも注文していただける顧客に絞って対応すると誓ったのである。
コラムワード検索
表示件数
ワード検索
本コラムに関する意見
Twitterにて受け付けます @megahit_jp