2016年にチーム内で勉強会をしたときの資料から起こしたものです。
実践的運用設計チェックリストすぎむら @SugiTK2018/05/10 (originally created as of 2016)
View Slide
はじめに「運用とはそもそも何をする仕事なのかをきちんと理解して、日々業務を行えるようにする」という目的を掲げまして、チーム内で勉強会をしたことがありました。 2016年頃のことです。そのときに作ったチェックリストです。使えそうなら適当に加工してみてください。
目次・運用は何のためにするのか意識は合っているか・開発から運用の流れ・システムの運用は何から始めるか・環境・監視・ログ・DB・ベンダー情報の追跡・システムの更新・インシデント管理・レポート・以上を踏まえて何をするか
運用は何のためにするのか・サービスを継続するための取り組み 機能の修正・改善 バグの修正 性能の改善 OS/ミドルウェアやアプリケーションのバージョンアップ☆リリースしたらあとは放っておけばお金が入って来る、ということにはなりません。☆サービスを継続していくための営みが運用です。
開発から運用の流れ・要求の取りまとめ サービス側から (新機能、外部サービスとの連携) 開発側から (保守性の向上、新しいミドルウェアへの対応) 運用側から (障害頻度の軽減、性能向上、可視化)・開発項目の確定と優先度付け・リリース時期を確定・開発、テスト・リリース ☆サイクルを回すことで、継続してサービスを提供することができます。☆このサイクルを回す速度はビジネスチャンスに影響します。
システムの運用は何から始めるか・サービスの把握・構成の把握 (ハードウェア(仮想)、OS、ミドルウェア、サービス、アプリケーション )・通信の把握 (ネットワークセグメント、 IPアドレス、プロトコル、データ )・リソースの把握 (CPU、メモリ、ディスク、プロセス、ネットワーク )・冗長性の把握 (想定する障害や高負荷、対策 )・アクセス制御や権限の把握 (ユーザ、グループ、秘密鍵 /公開鍵証明書、ドメイン名、期限 )・ユーザ管理 (追加、削除)・外部接続 (他サービス、アクセスキー、期限 )・ログ (アクセスログ、エラーログ、アプリケーションログ、ローテーション、保持期間 )・ベンダー情報 (サポートサイト、連絡窓口、ライセンス )・構成管理 (上記全て)☆初めから設計書などのドキュメントが完全に整備されていることはあまりありません。☆開発メンバーが残っていないこともありますし、彼らでも知らないこともあります。
環境・商用環境・ステージング環境・開発環境・アクセス制限 (アカウント管理、役割の設定)・環境差分の把握・リリース手順 リリース対象を確定 ステージング環境への配置、テスト 不具合の修正、再配置、テスト 商用環境への反映☆他にも環境を作ることがあります。☆サービスを継続して提供するため、を常に念頭に置くのがとても大切です。☆環境ごとにアクセス制限を設けます。開発者は商用環境には入れない、などのルールを実装します。
監視・何の情報を取得するために監視するか リソース監視 (CPU、メモリ、ディスク、ネットワーク、クラウド課金) プロセス監視 ログ監視 など・障害が発生したときに何をするか・監視設定は何を契機として見直すか☆人間が見て監視することには限界があります。☆障害を検知するためだけではありません。サービスを運用するための費用や、サービスの利用者数や売り上げなども監視の対象となり得ます。
ログ・ログの種類 OSのログ サービスのログ ミドルウェアのログ・ログレベル (緊急度、詳細度)・分析 入力、出力 処理の前後関係 頻度 エラーコード キーワードでの絞り込み 統計的解析☆ログには想定外のものが多数出て来ます。全部あらかじめ洗い出しておくのは不可能です。☆分析・加工して見やすくするのもとても大切です。運用設計や開発項目に入れておかないと、どこかでしわ寄せが来ます。
DB・バックアップ、リストア/リカバリ どの時点まで戻すのか (RPO: Recovery Point Objective) 戻すのにどれくらい時間を要するのか (RTO: Recovery Time Objective)・パフォーマンスチューニング (索引、インメモリ化、統計情報など)・リソース監視・権限管理 (ユーザ、パスワード、権限付与、権限剥奪)・アクセス制御 (DB、スキーマ、表)・初期化パラメータ・ログ☆DBにはサービスのためのデータが詰まっています。ほとんどのデータはビジネス上とても重要なものとなります。
ベンダー情報の追跡・バージョンアップ情報 新機能 削除された機能 互換性・製品のロードマップ チケットシステム 公開されたバグ情報 ソースコードの履歴管理情報・組織としての安定性 買収、解散、放置☆システム開発には他社(OSSを含む)のOSやミドルウェア、ハードウェア、サービスを必ず利用します。☆脆弱性情報だけを追いかけるのではなく、新機能にも追随していくことで開発や運用にかかる費用を削減できることもあります。☆5年も経つと製品自体がなくなってしまうこともよくあります。リスクとして認識しておきましょう。
システムの更新・サービスへの影響を把握 (停止、縮退、想定時間)・更新対象を把握 (サーバ、ネットワーク、設定、データ)・作業に影響する監視の抑止・更新作業を実施・監視の再開・構成管理への反映☆CI/CDが整備されていてblue-greenデプロイしますということはまだまだ容易ではないと感じています。☆作業中の監視の抑止はよく作業漏れするようです。あとでレポートを見たときにノイズになりますので注意しましょう。
インシデント管理・インシデントの種類 障害からの回復 サービス要求への対応・既知の障害かどうかの判断・脆弱性の分析と対策・ベンダーへの問い合わせ・対応履歴の管理・データの受け渡しと消去☆運用側で何かしなければいけないことがあればすべてインシデントです。☆インシデントとアクシデントは違います。サービスを継続して提供するために、あらかじめ備えられるものは設計しておきましょう。
レポート・サービスからの要求 バッチで作成して提供 要求を受けて随時作成して提供・運用レポート サービスの利用状況 リソースの利用状況 インシデントの発生状況 稼働率 ログ解析 状況の把握から 運用コストの見直し 設備投資の見直し 開発項目の優先度の変更☆定期的にサービスは見直されます。そのときの判断材料を提供するのがレポートです。☆できるだけ定型化して自動生成できるようにすると、毎度の差分も見やすくなります。
以上を踏まえて何をするか・日次作業・週次作業・月次作業・年次作業☆システムの規模やサービスの種類、利用者数、利用頻度などさまざまな要因を考慮して、運用作業を設計していきます。☆月次や年次での作業は、レポートの分析やシステムの見直しが主になるでしょう。
終わり
sugitk
bonotake
eiki
cyberarchitect
mitsuakitohei
opelab
nagiss
nktamago
miyakemito
pauli
riru
miyake
th0x0472
zakiwarfel
schacon
brianwarren
lauravandoore
malarkey
cromwellryan
philhawksworth
keavy
caitiem20
destraynor
hannesfritz
thoeni