新しいプロダクトをリリースする前にやるべきことっていろいろありますよね。
特に、決済とかOAuthみたいに外部サービス巻き込む系はAPIKeyの発行に数営業日かかることもあり、リリース日前日に「出してなかった！」とかなるとめっちゃ焦ります。（経験済み）
最近、新しいプロダクトをリリースしてまさにハマったというか、やっちまった経験をしたので同じ轍を踏まないようリストを書いておきます。
皆さんも、これもやったほうが良いぞ！というのがあればコメントにてお知らせください。
目次
- 外部サービスのAPIKey発行
- キャッシュ系の動作確認
- DNSまわり
- データベースのバックアップ体制確認
- 死活管理ツールのセットアップ
- GoogleAnalytics設定
- まとめ
それでは、Check it out!
外部サービスのAPIKey発行
今回この記事を書くきっかけになったもの。
今回は、twitter認証用と決済サービス用が審査必要にも関わらず、審査を出すのがリリース前々日、しかも出した翌日には追加の説明文を送ってくれ、、と言われるアグレッシブな事態に。
ツイッターは色々なブログを読んでいると7日間かかった、みたいなことも散見されたので焦りました。結果的には追加の説明文を送った12時間ぐらいに審査が通り、無事本番リリースに間に合いました。
決済も同じく。
二度とこの焦り方はしたくない、、
キャッシュ系の動作確認
今回リリースしたサービスはフロントをnuxt+herokuな構成で進めましたがここにも罠が。
新しいコミットが全然反映されない！
更新すると反映されるからキャッシュだ！
けど異様にキャッシュがキツい！
しかも同じ状況になってるissueも見つからない！
キャッシュ系は気付きにくいのと、キャッシュのせいで修正してもクライアントによってエラー内容が変わってくるので予め適切に設定されているか確認しましょう。
ちなみに、今回はnuxt.cinfig.jsに
build: {
analyze: true
}
と、オプションをつけっぱなしにしていたことが原因でした。
DNSまわり
メールを送る際、なるべくスパム認定されない為にドメインのDNSにDKIMレコードやSPFレコードの設定をすることが推奨されています。
が、、今回使っているMTA(sendgrid)とonamae.com のレンタルサーバープランのNSの相性が最高に最悪で、まさかのdkimなど設定できない問題に。
これは今でも続いていて、NSの変更が必要になりました。
データベースのバックアップ体制確認
無事リリース完了！お疲れ様でした！
と、リリース後数日してバーボン片手にdb設定眺めていたらまさかのノーバックアップ。
死ぬほど焦ってすぐセットアップしましたが、heroku+heroku postgresの環境だとサービスの一時停止とdb移管が必要になります。
深夜にめちゃくちゃ慎重に作業しましたが、リリース前にやってれば安心安全だったよな、と反省。
死活管理ツールのセットアップ
まぁリリースした直後にセットしよう、と甘い考えしてたら意外にセットアップかかったので先にやりましょう。
そして、、その際に入れたのがフロントとapiそれぞれが生きてるかの監視だけで、統合的な監視になっていなく、、結果、数日間apiが全然違う方向を向いていたという致命的なミスを起こしました。
原因は少し複雑な設定ミスでしたが、想定してないことが起きたときに気づくのが死活監視。api、db、最低限の動作が問題なくできるか統合的な監視になるよう予め設定すべきでした。
GoogleAnalytics設定
リリース当日に、あれ、なんか設定変じゃない？と気付いて修正した事案。
もちろん修正作業より前のデータは不正データが入っていて使えません。
トラッキングが正しくできているかももちろん、analytics上でもcvとかは先にセットしないと見れないので予め計測したいデータを洗い出して設定しておきましょう。
まとめ
振り返ると、「おいおい大丈夫かよ」とか「普通対策うっておくだろ」と思えます。
が、スクラッチからシステム開発する際の怖いところで、やるべきことが多岐にわたるし、責任が分散しがちで本当に抜け落ちていました。
ということで、ここに羅列したものはどれも「もっと早く気づくべきだった！」なことなので、チェックリストとしてキチンと全部潰しておきましょう。