Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実践的運用設計チェックリスト
Search
sugitk
May 10, 2018
Technology
2
1.2k
実践的運用設計チェックリスト
2016年にチーム内で勉強会をしたときの資料から起こしたものです。
sugitk
May 10, 2018
Tweet
Share
More Decks by sugitk
See All by sugitk
テクニカルサポートのお仕事
sugitk
5
2.7k
What's new in Ansible Automation Platform 2.1
sugitk
2
2.4k
Ansible テクニカルサポートの現場から
sugitk
3
2k
english_on_business
sugitk
1
470
RHCSA / RHCE
sugitk
0
4.9k
Oracle Database のお話
sugitk
0
430
ソフトウェアライセンスのお話
sugitk
2
430
Other Decks in Technology
See All in Technology
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
5
860
技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話
niftycorp
PRO
0
100
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
190
Amazon Q Developerの無料利用枠を使い倒してHello worldを表示させよう!
nrinetcom
PRO
2
110
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
170
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
120
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
210
NFV基盤のOpenStack更新 ~9世代バージョンアップへの挑戦~
vtj
0
350
実は強い 非ViTな画像認識モデル
tattaka
2
1.2k
Windows の新しい管理者保護モード
murachiakira
0
200
分解して理解する Aspire
nenonaninu
2
1k
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
310
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
Docker and Python
trallard
44
3.3k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
The Language of Interfaces
destraynor
156
24k
Large-scale JavaScript Application Architecture
addyosmani
511
110k
YesSQL, Process and Tooling at Scale
rocio
172
14k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Unsuck your backbone
ammeep
669
57k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
7
640
A Philosophy of Restraint
colly
203
16k
Statistics for Hackers
jakevdp
797
220k
Transcript
実践的運用設計チェックリスト すぎむら @SugiTK 2018/05/10 (originally created as of 2016)
はじめに 「運用とはそもそも何をする仕事なのかをきちんと理解して、日々業務を行えるようにする」 という目的を掲げまして、チーム内で勉強会をしたことがありました。 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デプロイしま
すということはまだまだ容易ではないと感じていま す。 ☆作業中の監視の抑止はよく作業漏れするようで す。あとでレポートを見たときにノイズになりますの で注意しましょう。
インシデント管理 ・インシデントの種類 障害からの回復 サービス要求への対応 ・既知の障害かどうかの判断 ・脆弱性の分析と対策 ・ベンダーへの問い合わせ ・対応履歴の管理 ・データの受け渡しと消去 ☆運用側で何かしなければいけないことがあれば
すべてインシデントです。 ☆インシデントとアクシデントは違います。サービス を継続して提供するために、あらかじめ備えられる ものは設計しておきましょう。
レポート ・サービスからの要求 バッチで作成して提供 要求を受けて随時作成して提供 ・運用レポート サービスの利用状況 リソースの利用状況 インシデントの発生状況 稼働率 ログ解析
状況の把握から 運用コストの見直し 設備投資の見直し 開発項目の優先度の変更 ☆定期的にサービスは見直されます。そのときの 判断材料を提供するのがレポートです。 ☆できるだけ定型化して自動生成できるようにする と、毎度の差分も見やすくなります。
以上を踏まえて何をするか ・日次作業 ・週次作業 ・月次作業 ・年次作業 ☆システムの規模やサービスの種類、利用者数、 利用頻度などさまざまな要因を考慮して、運用作業 を設計していきます。 ☆月次や年次での作業は、レポートの分析やシス テムの見直しが主になるでしょう。
終わり