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.1k
Ansible テクニカルサポートの現場から
sugitk
3
1.9k
english_on_business
sugitk
1
470
RHCSA / RHCE
sugitk
0
4.8k
Oracle Database のお話
sugitk
0
400
ソフトウェアライセンスのお話
sugitk
2
400
Other Decks in Technology
See All in Technology
Amazon CloudWatch Network Monitor 導入ガイド_デモ説明付き
yukimmmm
0
150
今、始める、第一歩。 / Your first step
yahonda
2
660
元旅行会社の情シス部員が教えるおすすめなre:Inventへの行き方 / What is the most efficient way to re:Invent
naospon
1
170
フロントエンド メタフレームワーク 選定の際に考えたこと
yuppeeng
0
590
第23回Ques_タイミーにおけるQAチームの在り方 / QA Team in Timee
takeyaqa
0
140
SREの前に
nwiizo
11
2.5k
신뢰할 수 있는 AI 검색 엔진을 만들기 위한 Liner의 여정
huffon
0
530
AWS パートナー企業でテクニカルサポートに従事して 3年経ったので思うところをまとめてみた
kazzpapa3
1
200
フルカイテン株式会社 採用資料
fullkaiten
0
39k
What to do after `laravel new`
mattstauffer
0
130
Mini Tokyo 3D × PLATEAU - 公共交通デジタルツインにリアルな風景を
nagix
1
230
透過型SMTPプロキシによる送信メールの可観測性向上: Update Edition / Improved observability of outgoing emails with transparent smtp proxy: Update edition
linyows
2
150
Featured
See All Featured
Teambox: Starting and Learning
jrom
133
8.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
GitHub's CSS Performance
jonrohan
1030
460k
Scaling GitHub
holman
458
140k
Done Done
chrislema
181
16k
Building Applications with DynamoDB
mza
90
6.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Fashionably flexible responsive web design (full day workshop)
malarkey
404
65k
Writing Fast Ruby
sferik
627
61k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
810
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
700
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デプロイしま
すということはまだまだ容易ではないと感じていま す。 ☆作業中の監視の抑止はよく作業漏れするようで す。あとでレポートを見たときにノイズになりますの で注意しましょう。
インシデント管理 ・インシデントの種類 障害からの回復 サービス要求への対応 ・既知の障害かどうかの判断 ・脆弱性の分析と対策 ・ベンダーへの問い合わせ ・対応履歴の管理 ・データの受け渡しと消去 ☆運用側で何かしなければいけないことがあれば
すべてインシデントです。 ☆インシデントとアクシデントは違います。サービス を継続して提供するために、あらかじめ備えられる ものは設計しておきましょう。
レポート ・サービスからの要求 バッチで作成して提供 要求を受けて随時作成して提供 ・運用レポート サービスの利用状況 リソースの利用状況 インシデントの発生状況 稼働率 ログ解析
状況の把握から 運用コストの見直し 設備投資の見直し 開発項目の優先度の変更 ☆定期的にサービスは見直されます。そのときの 判断材料を提供するのがレポートです。 ☆できるだけ定型化して自動生成できるようにする と、毎度の差分も見やすくなります。
以上を踏まえて何をするか ・日次作業 ・週次作業 ・月次作業 ・年次作業 ☆システムの規模やサービスの種類、利用者数、 利用頻度などさまざまな要因を考慮して、運用作業 を設計していきます。 ☆月次や年次での作業は、レポートの分析やシス テムの見直しが主になるでしょう。
終わり