[WIP] 新しいプロジェクトを始める際に考えておいたほうがいいことリスト #非機能要求

SIであろうがなかろうが関係なく、このへん一度は考えておかないとあとでツラくなる。

"非機能要求", "横断的関心事", "ソフトウェアアーキテクチャ"なんかに近いと思うけど、そこまで整理できてないし、非機能要求仕様定義ガイドラインとか非機能要求グレードで整理されたことだとは思うので、あらためてこれらのドキュメントも確認しておきたい。

また、Twelve-Factor Appの考え方に則るというのも、可搬性、可用性を上げるのに役に立ちそうなので、それも入れ込みたい。

参考元/引用元

tl;dr チェックリスト

もうちょっと整理したい。今後も手直ししていく。

セキュリティ
- なにかが漏えいした際のリスクは？保護すべきものはなに？
- リスクに対応してどうやって保護する？
秘匿情報の管理
- 依存サービス（DBとか外部APIとか）へのクレデンシャルはどう管理する？
パフォーマンスとスケーラビリティ
- 求められる性能は？
  - レイテンシー
  - 単位時間辺りの処理数
- パフォーマンス監視はする？できる？
- 負荷テストはやる？どのていどやる？
- 本番で稼働したままダンプだせるようにする？
- 本番環境で原因究明をする手段はある？
- DNS解決は問題になりやすいので要注意。キャッシュする仕組みをいれておく？
可用性とレジリエンス
- 動いているかの監視の仕方は？zabbixとかで監視できる？
- APIでバージョンとモードを返すのは必要？
- 例えばadmin/versionみたいなAPIがあって、レスポンスが0.1.4_stagingみたいなのだと問題があったときの解決の助けになるかも
- エラーハンドリングどうする？監視システムに通知する？
- 開発者への通知はどうやる？メール？チャット？
- supervisorによる監視は必要？autorestartは？
- daemontools, upstart, systemdとかでデーモン化する？
- サブシステムがダウンしてたらどうなる？
- どんなときならクラッシュしてもいいの？
- グレースフルリスタート、シャットダウンは必要？サービス止めるときはどうする？
- ホットデプロイ的なのは必要？
- 設定の動的読み込みは必要？
ログ
- ログの出力先は？ローテーションルールは？保存する場所は？保存する期間は？ログの漏れは許容できる？
- ロギング設定は外部ファイルに切り出されていて、柔軟に変更できる？
非同期処理
- バッチやワーカーみたいなバックグラウンドでの処理は必要？
- どうやって起動させる？cron？ジョブキュー？RundeckやJP1みたいなジョブ管理システム [ref: Jenkins - cronの代替になりそうなジョブ管理ツールのまとめ - Qiita] 入れる？
国際化
- 国際化必要？
- 国際化フレームワークはコードとデータの分離に役立つ側面もあるので、導入時期を検討するとよい
発展性（スケーラビリティ）
- ひとつのサーバーで処理しきれなくなったときにスケールアップ、スケールアウトできる？
アクセシビリティ
- 対象のユーザーは？どんな環境のユーザー？
開発リソース
- 誰がメンテナンスするの？
- そのシステムはどれくらい長く使うの？
配置場所
- どこのサーバー？
- そのサーバーに求めるSLAは？
- だれが管理してる？
- サーバーのシステム更新はどうする？
- サーバー自体の監視はしてる？
- リリースは自動化する？
規則
使用性（ユーザビリティ）

詳細

各項目について詳細を書いてもいいかも。例えばこんな感じで。

ロギング

チェック項目

ロギング設定は外部ファイルに切り出されていて、柔軟に変更できる？
ログの出力先は？
ローテーションルールは？
保存する場所は？
保存する期間は？
ログの漏れは許容できる？

検討すべき理由

ログはとても重要、なぜなら、とかなんとか

分析ソースとしてのログ
- ビジネス
- 障害
アーカイブされるログ

ソリューションの例示

syslogロガーに流してセントラルrsyslogサーバーでアグリゲーション
Fluentdエージェントにログを渡して、アグリゲーションサーバーに送る。この場合のアグリゲーションサーバーはローカルネットワークに建てたり、TreasureData, BigQueryなどの外部サービスに送るのもよくある。んで、ElasticSerach, Kibanaでグラフ化とか。海外ではFluentdの代わりにLogStashがメジャーな印象。
ログのアーカイブには、ローカルネットワークのストレージを使ったり、AWS S3やAWS Glacierを使ったりとかもある