この記事はモチベーションクラウドシリーズアドベントカレンダー2021の12日目の記事です。
こんにちは。モチベーションクラウドシリーズのテックリードをしている江上です。
突然ですが、今までに「常識」という言葉で傷ついたり、傷つけた経験はありませんか？
例えば、失敗した時に「なんでxxxしてないんだ！そんなの常識だろ！！」と先輩に怒られたり、「洗濯物はパンパンしてから干す！常識でしょ！！」と奥さんに怒られたり。。。
常識って、その人やその界隈では当たり前すぎるために、継承が困難。なのに、知らないと事故につながるとても大事な知識です。
そこでこの記事では、知らないと事故につながるような、エンジニアの隠れた常識を記していこうと思います。
あくまで、僕が今まで経験した職場や、他人から聞いた話をまとめた個人的な見解です。
「他にもこんな常識あるよ！」という方はコメントで是非教えていただければと思います。
※ 各所でRuby on Rails + MySQLを前提にした表現が出てきますが、自身が使っているものに読み替えていただければと思います
1. リリースしたら本番確認！
ある日の昼。長い時間かけてようやく完成した機能のリリースが完了。「仕事終わったー！」と思ってお茶を飲みに席をたったら、エラーのアラートが鳴り響く。 なんて経験ありませんか？
リリース前に本番データ使ってテストを実施していたとしても、リリース後の確認が終わらなければ正しく動いてるかどうかはわかりません。
例えば、本番でだけサーバーの設定が違うこともあります。テストしていたデータと現状のデータ差分はどうしても発生しますし、同時リリースした機能によって動かなくなることもあります。テストした環境が本番環境でない限りどこかに差分が出てしまいます。本番にリリースしたら必ず動作確認を行いましょう。
特に、データ修正スクリプトの実行結果の確認は大切です。データの不整合になった場合、エラーになって画面表示されないならまだラッキーな方で、最悪の場合ユーザーに間違った情報を届けてしまうことになります。検証クエリを用意したり、変更前後のログを見ることで意図した結果になったことを確認しましょう。
2. 不用意にnull許可しない！
「テーブル追加しました！」と自信満々でPR出したら「null許可？ defaultはnull？ MySQLだとunique index効かなくない？」みたいな怒涛のフィードバックを受けた経験ないですか？ちなみに僕は最近しましたw
Railsなどで特に指定なく定義するとnull許可になります。null許可していても機能としては動くので個人開発などでは気にしなくていいかもしれません。しかし、許可していると思わぬところでnullが入ってしまうことでエラーが発生し、画面が表示されなくなってしまうなどの事故につながります。許可しているnullはいつかどこかで入るのです。
また、「type列がnullの場合はallという意味にする」など、nullに特別な意味を持たせるのもあまりお勧めできません。想像が難しい暗黙の意味を持たせてしまうことは事故の原因になります。
DBの設計で防げる事故は多いので、しっかり周りと相談しましょう。弊社でもschemaの変更ファイルだけはGithubのCODEOWNERの機能を使って、必ず複数の目を入れるようにしてます。
3. 消すときは慎重に！
デプロイ中に、migration適用したら急にエラーが来たり、リリースして数分古いパラメータが飛んできてエラーになる みたいな経験ありませんか？
アクセス数が一定量を超えたアプリケーションでは一度は目にするエラーな気がします。
migration適用~アプリ再起動でのエラーは、実際のDBのschemaとアプリがキャッシュしてるschemaと不一致が起きることが原因です。テーブルの列を削除する場合は、参照をなくし、ignore_columnsなどであらかじめアプリケーションの管理下から外しておきましょう。
リリース後に古いパラメーターが飛んでくるのは、ユーザーがリリース前のhtmlを読み込んでいたことが原因です。ネイティブアプリではかなり意識すると思いますが、webだと忘れがちですよね。古いパラメータも受け付けれるようにするか、クライアントとバージョン不一致の場合リロードさせるなどの対応をしておきましょう。
テーブルの列もAPIのエンドポイントやパラメータも消すときは、必ずログを確認したり、削除予定の処理に事前にアラートを仕込んでおくなど、データに基づいて行動しましょう。
4. パラメーターを信用してはならない！
「『' OR 1=1--』ってパラメータ来たらどうするの？」とフィードバックをもらって、「なんじゃその呪文？」って思った経験ありませんか？（フレームワークでプレースホルダー使ってる限りは気にする必要ないので、そんなフィードバックする人もういないかもしれませんね...）
フレームワークの教科書には書いてないけど、顧客に提供するアプリケーションをつくるなら絶対に知っておかないといけないセキュリティに関する知識。弊社でも、徳丸さんの安全なWebアプリケーションの作り方はアプリケーション触る上での必読書にしています。
上記のような特殊なパラメータだけでなく、idをそのまま信用していたり、検証方法が間違っていると他ユーザーの情報が見えてしまうなどサービスの存続に関わる事故に発展します。
テスト項目に含めるだけでなく、定期的にセキュリティツールの自動検査を行ったり、脆弱性診断を定期的に行うことで防御を固めましょう。
5. 大きい修正だけじゃなく、小さいバグ修正も同じくらい危険！
「エラー直したんでリリースします」「あー、また違うところでエラーがー！！！」みたいな経験ありませんか？
Googleの研究によるとバグ修正のための変更の40%が新たなバグを混入することがわかっています。
経験上、小さい修正が事故につながるケースは、焦りか油断がある場合が多いように思います。
バグ修正をしているときは視野も狭くなってしまいます。特に本番でエラーが出ているなか修正をしている場合は、焦る気持ちも相まって余計にそうなってしまいますよね。僕も1min止めたら諭吉が何十枚も消えるアプリケーションに関わっていたときは、それはそれは気が気じゃありませんでした。（当時CanaryリリースとかBlue/Greenもなかったですしね）
緊張する状態でない場合、逆に簡単な修正だという油断も事故につながります。
小さいからこそ細心の注意をもって修正を行いましょう。
最後に
いかがだったでしょうか？
自分のエンジニア人生を振り返りつつ、あまり伝える機会はないけども事故を起こさないために大事だと思った観点をまとめてみました。
「他にもこんな常識あるよ！」という方はコメントで是非教えていただければと思います。