tweeeetyのぶろぐ的めも

アウトプットが少なかったダメな自分をアウトプット<br>\(^o^)/

【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - Build結果をSlack通知

はじめに

仕事でcircleciをなんとなーく使っていますが 使いこなしたくなったので改めて個人でもいろいろ試してみるメモです。

githubとの基本的な連携は以下に記載してますのでご参考ください 【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - githubとの連携まで

アジェンダ

  1. Githubと連携する
  2. Slackへ通知する方法の簡単な説明
  3. SLackへ通知する - Incoming WebHooks
  4. Slackへ通知する - CircleCI

1. Githubと連携する

まず、githubにpush(pull request)して、
build結果をSlack通知する流れをものすごくはしょって説明します。

f:id:tweeeety:20180502182937p:plain

  1. 人が、ローカルにてgithubにpushする(pull request)
  2. githubが、pushをトリガーにCircleCIにbuild requestを送る
  3. CircleCIが、コンテナを立ちあげてyamlファイルに従ってbuildを実行する
  4. CircleCIが、結果をgithubに通知する
  5. CircleCIが、結果をslackに通知する
  6. Slackが、人のPCにNotificationする(そういう設定してればですが)
  7. 人が、通知を受けてgithubを見に行く(と、結果が出てる)

1〜4については、github<->CircleCIの基本的なci設定のため今回の通知そのものとは関係ありません。

という事で、今回は 5. CircleCIが結果をslackに通知 の部分についてになります。

補足

基本的なci設定

冒頭にも記載しましたが、基本的な連携については以下をご参考ください 【CircleCI】CircleCI 2.0からはじめる個人での簡単なCI導入方法 - githubとの連携まで

サンプルリポジトリ

今回は、pushするリポジトリとして以下を用意しました。
https://github.com/tweeeety/go-test-circleci-slack-sample

前準備

また、github<->circleCIでciを回すための基本的な連携は終わっている状態です
f:id:tweeeety:20180502183314p:plain

2. Slackへ通知する方法の簡単な説明

CircleCIからSlackへ通知する方法は以下の2通りあります(201804現在)

  1. Incoming WebHooksを使う
  2. CircleCIアプリを使う

どうやって通知するの?

両者、基本的に通知方法はほとんど変わりません。
基本的には以下のような仕組みです。

  • Slackアプリ設定画面でWeb Webhook URLが発行される
    • このとき通知先チャンネルも指定する
  • CircleCIにWeb Webhook URLを登録する
  • CircleCIがbuild後にWeb Webhook URLに対して通知を送る

どうちがうの?

Slackに通知するという点においては、使ってみた感じほとんど違いはありません。
CircleCIアプリの方が、デフォルトでCircleCIからの通知だよというアイコンやらが設定されているのでめんどくさがり屋さんには良いと思います。

3. SLackへ通知する - Incoming WebHooks

簡単ではありますが、Incoming WebHooks での通知設定を参考程度に載せておきます。

Slack側での設定

https://<チーム名>.slack.com/apps を開きます
f:id:tweeeety:20180502183416p:plain

アプリの検索フォームにWebHooksなどをいれるとIncoming WebHooksが表示されるので選択します。
f:id:tweeeety:20180502183427p:plain

Incoming WebHooks画面にてAdd Configurationを選択します。
f:id:tweeeety:20180502183437p:plain

Incoming WebHooksの設定画面が開くので、
通知するチャンネルを選択してAdd Incoming WebHooks integrationを押します
f:id:tweeeety:20180502183450p:plain

設定画面にて、Webhook URL が発行されます。
これを後で使うのでコピるなり画面を開いておくなりします。
f:id:tweeeety:20180502183501p:plain

そのまま画面下にいってSave Settingで完了です。 f:id:tweeeety:20180502183518p:plain

CircleCI側での設定

project(リポジトリ)のbuildページで設定的なアイコンをクリックして設定画面を開きます。
f:id:tweeeety:20180502183532p:plain

NOTIFICATIONS > Chat Notificationsを開きます f:id:tweeeety:20180502183559p:plain

Slackの枠があるのでWebhook URL
先ほど発行したsitaWebhook URLを入力してSaveします。
f:id:tweeeety:20180502183613p:plain

ためしに&Test Hookを押すと、Slack側にこんな感じで通知されると成功です。
f:id:tweeeety:20180502183625p:plain

pull requestを送ってみる

ローカル

ローカルで適当に修正してpush します

# 適当にブランチ切っておく
$ git checkout -b notify-sample

# 適当に修正してpush
$ vi なにかしら適当に修正
$ git add .
$ git commit -m 'notify sample pull request'
$ git push origin notify-sample
circleci

#2としてbuildが走ります f:id:tweeeety:20180502183909p:plain

slack

buildが終わると通知されます f:id:tweeeety:20180502183918p:plain

4. Slackへ通知する - CircleCI

全体的に基本的な流れはIncoming WebHooksと変わりありませんが、
Slack側のみ説明しておきます。

Slack側での設定

探すアプリをIncoming WebHooksではなくCircleCIで検索します。
f:id:tweeeety:20180502183933p:plain

CircleCIアプリが開くのでInstallを押します f:id:tweeeety:20180502183947p:plain

チャンネルを選択してAddCircleCI Integrationを押します f:id:tweeeety:20180502183959p:plain

Incoming WebHooksと同様に
Webhook URLが発行されるのでSave Integrationを押して設定完了です。

CircleCI側での設定

CircleCI側については、Incoming WebHooksとまったく同じ手順です。

pull requestを送ってみる

これもIncoming WebHooksとまったく同様です。

おわり

SlackもCircleCIもWebから操作できるので楽チンです!
enjoy!\(^o^)/

【slack】GitHubとSlackを連携させる - 新しいgithubアプリでpull req通知を受け取るまで

はじめに

GithubとSlack連携は以前から使ってましたが
slackと連携するgithubの新しいアプリが出たらしいので使ってみた感じをメモ

2018/04現在、以前のgithub連携アプリは
Github Notifications (レガシー)
と呼ばれるようです

アジェンダ

  1. 連携させる
  2. 設定を変える
  3. /githubコマンドの使い方

1. 連携させる

https://slack.github.com/ にて連携設定を行います。
連携はwebのみで行えます。

webを開く

https://slack.github.com/ を開いてAdd to Slackを押します
f:id:tweeeety:20180425222358p:plain

アクセス権限を確認

アクセス権限を確認し「Continue」を押します
f:id:tweeeety:20180425222411p:plain

チャンネル選択

アプリがアクセスできるチャンネルを選択します。
とりあえずAll Public Channelsを選択しInstallを押して先に進みます。

2. 設定を変えるにて後述しますが、設定は後で変更できます。
f:id:tweeeety:20180425222423p:plain

Installと連携を確認

Installされるとアプリを開くダイアログが表示されます
f:id:tweeeety:20180425222619p:plain

Slack.appを開くとこんな画面で出迎えてくれます
f:id:tweeeety:20180425222723p:plain

2. 設定を変える

設定を変えるには以下から行います。
https://<チーム名>.slack.com/apps/manage

設定するアプリを探す

https://<チーム名>.slack.com/apps/manageを知らなくてもアプリからも開けます。

  • slackアプリのメニューからCustomize Slackを開きます f:id:tweeeety:20180425222741p:plain

  • Configure Appsを開きます f:id:tweeeety:20180425222806p:plain

  • InstallしたGitHubがあるので選択します f:id:tweeeety:20180425222820p:plain

設定を変える

Settingsを選択します f:id:tweeeety:20180425222841p:plain

Install時の設定でAll public channelsを選択してしまったとしてもこの画面で変更できます。
本来は極力権限はしぼるべきでしょう。
f:id:tweeeety:20180425223155p:plain

補足

特定のChannelのみにした場合でも、
あとからslack側の追加したいchannelで
/invite @github と発言することで後から追加できます

3. /githubコマンドの使い方

使うコマンド

slackのコメント欄にて以下のコマンドを発言することでリポジトリの設定が行えます

コマンド 意味
/github subscribe owner/repo 指定したリポジトリの通知を受け取ります
/github unsubscribe owner/repo 指定したリポジトリの通知をやめます
/github subscribe owner/repo 機能 指定したリポジトリ機能(※1)の通知を受け取ります
/github unsubscribe owner/repo 機能 指定したリポジトリ機能(※1)の通知をやめます
/github subscribe list 通知設定したリポジトリを表示します

※1: 機能には、
↓に記載しているデフォルト通知設定 の機能を個別に指定します。

具体的にはissuespullscommentsなどです。

デフォルト通知設定

  • デフォルトで通知を行う機能
    • issues (イシュー)
    • pulls (プル)
    • statuses (ステータス)
    • コミット
    • deployments (デプロイメント)
    • public (パブリック)
  • デフォルトで通知されない機能
    • reviews (レビュー)
    • comments (コメント)
    • branches (ブランチ)
    • commits:all (すべてにコミット)

特定のリポジトリのsubscribe

ためしにこのリポジトリをsubscribeしてみます
https://github.com/tweeeety/github-slack-new_app

slack上でsubscribeするリポジトリを指定

/github subscribe tweeeety/github-slack-new_app と打ちます

f:id:tweeeety:20180425223256p:plain

Githubアカウントと連携する

SLack上にConnect GitHub accountというボタンが現れるのでおします f:id:tweeeety:20180425223305p:plain

Github上で連携する

Authorize githubを押します
f:id:tweeeety:20180425223321p:plain

押すとSlack上にはSuccess!と通知がきます f:id:tweeeety:20180425223346p:plain

Github上でリポジトリ設定をする

続けてGithub側で
この連携がアカウントの全てのリポジトリを対象とするか、特定のリポジトリとするかを選択します f:id:tweeeety:20180425223413p:plain

完了するとSubscribed to...という通知がきます f:id:tweeeety:20180425223425p:plain

pull requestを送ったsubscribeを確認

https://github.com/tweeeety/github-slack-new_app/pull/1
ためしにこのpull requestを送ってみた結果です。
f:id:tweeeety:20180425223447p:plain

特定のリポジトリの機能のsubscribeをする/やめる

すでに出てきましたが、以下のようなコマンドで機能に対してのsubscribeをする/やめるができます

  • issue(プルリク)に対してsubscribeする
  • issue(プルリク)に対してsubscribeやめる

補足

2018/04現在、EnterpriseSlack Enterpriseには対応してないようです。

以下の公式リポジトリのREADMEに記載があります

This app officially supports GitHub.com and Slack.com but the team plans to support GitHub Enterprise and Slack Enterprise Grid in the future.

おわり

chatOps的にslackから設定ができるのはとっても便利ですね\(^o^)/

docやブログに書くコマンド例の構文や表記の規則

はじめに

docやブログやwikiを書くとき、
こんな感じでコマンド例を載せることは多いと思います。

hoge {fuga|piyo} [-f <filename>]
※ 適当です

そんなとき、
毎回{}[]<>辺りを迷うので、これはちゃんと自分の中でまとめられてないからだな、と。
そんな自分のためのメモです。

規則

構文規則 説明
[ ]
大括弧
[ ](大括弧)は、任意のオプションであることを示します。
大括弧で囲まれていないものの指定は必須です。
[-h host_location]
※ なくても良い
{ }
中括弧
{ }(中括弧)は、相互に排他的な一連のオプションを示します。その中のどれか1つを指定する必要があります。 {-i IP_address | -n host_name}
※ どちらか必須
|
垂直バー
|(垂直バー)は、相互に排他的なオプションを区切ります。 {-i IP_address | -n host_name}
※ どちらか必須
...
省略符号
...(省略符号)は、直前のオプションが異なる値で複数回繰り返し指定可能であることを示します。
大括弧の内側でも外側でも使用できます。
[-x files]...
※ -x file1 -x file2 -x file3

[-x file...]
※ -x file1 file2 file3
< >
山かっこ
< >(山かっこ) は変数を示します。この値は必ず指定する必要があります。 -f <file_name>
\
バックスラッシュ
コマンド業の継続を表す記号です hoge fuga \
-a piyo\
-b poko
太字 正確に入力する必要があるリテラル情報を示します nids-c config_filename
イタリック イタリック・テキストは変数で、それが表現するものと置換する必要があります file_name
" "
二重引用符
オプションを囲む""(二重引用符)は、1つのオプションとして解釈されることを指定します -L "-p 9495"
' '
二重引用符
オプションを囲む''(単一引用符)は、1つのオプションとして解釈されることを指定します ls 'part 1'

※ 参考サイトから説明はお借りしている部分があります

参考サイト

おわり

コマンドラインのコンテキストによっても若干違いはあると思いますが、だいぶ自分の中でもすっきりした気がします\(^o^)/

【設計】みんなが知っておくべき運用設計のノウハウ を読んだメモ - 6章:移行フェーズ

はじめに

タイトルの通りですが、運用って意外に難しいですよね。

仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか?

  • 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...?
  • ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
  • ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ...   サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。

読んだ本

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

もくじ

  1. 移行フェーズ
    • 6.1.移行とは

「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。

読んだ感想

この章では運用設計の範疇ではないが、運用と関わりが深い移行について解説されています。

移行については、情報をあまり見た事がなかったのでこうして本にまとめられているのはありがたいです。

6.1.移行とは

移行について

  • 移行とは
    • 完成したシステムを、利用者が利用できるように新システムに切り替えること
    • 運用設計の範疇ではなくプロジェクト全体の範疇
    • ただし、移行後に運用開始のため運用設計が深く関わる
  • 導入するシステムの種類
    • 新システムの追加
      • 新たな作業や業務が発生する
      • 事前説明やユーザ教育が必要
    • 既存システム更改の場合
      • データを引き継ぐ場合、デグレや移行時間の確保が必要
      • 平行運用期間を設ける場合、最新データの扱いの検討が必要
  • 移行の方法
    • 一括移行
      • 全体のシステム停止が可能な場合や複雑で段階移行の影響が読めない場合に採用
      • 移行コスト、手間、時間は最小
      • コンティジェンシープランの考え方が簡単
      • すべての利用者に影響があるためリスクは高い
    • 段階移行
      • 全体でシステム停止できな場合、データが多く一括移行できない場合に採用
      • 移行中は新旧2つのシステム運用が発生する
      • 移行コスト、手間、時間はやや高い
      • コンティジェンシープランの考え方はやや複雑
      • 移行した利用者へのみ影響があるためリスクはやや少ない
    • 平行運用
      • 現行システムと新システムの互換性が重要な場合に採用
      • 移行コスト、手間、時間は高い
      • コンティジェンシープランの考え方は複雑
      • 新システムに問題があっても、旧システムが利用できるためリスクはほぼない

移行の実施

  • 移行計画書
    • 移行概要
      • 移行期間
      • 移行時の業務制限
      • 他システムへの影響
      • 新業務の開始時期
      • 失敗時の影響
      • 切り戻し方針
    • 移行対象
      • 対象データ
      • 移行先
      • ネットワークの切り替え有無
      • 移行後の設備
      • 移行ツール
    • 移行中の影響
      • 利用者への影響
      • データへの影響
      • 運用への影響
    • 移行テスト
      • リハーサル実施方針
      • リハーサル時期
      • リハーサル体制
      • リハーサルスケジュール
    • 移行スケジュール
      • 移行スケジュール
        • 15分〜30分単位で作成し、タスクの依存関係をはっきりさせる
        • 問題がある場合のコンティジェンシープラン発動判断基準も決める
      • ユーザの利用スケジュール
      • ユーザの教育スケジュール
    • 移行体制
      • 当日の体制
        • 移行継続判断を実施するリーダを決める事が重要
      • 移行前後の運用体制
      • ユーザ教育の体制
      • リハーサルの体制

移行時の注意事項

移行に関するトラブルの影響判断を行うため、各チームのリーダクラスがアサインされている事が望ましい

  • 移行全体の判断を行う
  • 問題管理と進捗管理を行う
  • トラブルの影響判断を行う
  • 状況整理、関係者に定期的に周知を行う
移行がうまくいかないと、プロジェクト全体が失敗した雰囲気になる。  
綺麗なドキュメント、しっかりしたテストがあっても、移行が失敗すると台無しになる場合も。

おわりに

移行計画や移行実施って意外にむずかしく、
どんなにテストをしていても移行を雑にやるとすぐ障害につながったりするので個人的には大事にしているフェーズです。

終わりよければすべて良しとはよく言った物で、
終わりがダメでダメな感じ...という事にならないように気をつけたいものです\(^o^)/

紹介

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

【設計】みんなが知っておくべき運用設計のノウハウ を読んだメモ - 5章:テストフェーズ

はじめに

タイトルの通りですが、運用って意外に難しいですよね。

仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか?

  • 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...?
  • ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
  • ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ...   サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。

読んだ本

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

もくじ

  1. テストフェーズ
    • 5.1.テストとは
    • 5.2.テストの種類と内容

「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。

読んだ感想

この章ではテストにおける運用テストとはという形で説明されています。

テストの分野は本当におくが深いので
個人的にはいわゆるQA/QC的な意味合いでのテストも別で勉強したいなと思いました。

5.1.テストとは

運用設計としてのテストフェーズは運用テストを行うこと

テスト仕様書

  • 項目
    • テスト項目番号
    • テスト項目名
    • 実施内容詳細(手順)
    • 合否判定基準
    • 実施結果
    • 実施年月日
    • 実行者
    • 課題管理晩冬
  • 項目とは別にあると良いもの
    • テスト計画書
      • テスト実施環境
      • テストの目的
      • 概要
      • 実施前提
      • 全体の実施予定

問題の管理方法

ランク付けして管理すると良い

  • ランク
      • 問題の対応/回避方法が不明
      • 対方方法は明確だが、スケジュールや費用に影響がある
      • 問題の対応/回避方法は明確
      • 方法が複雑で他の要素への影響が懸念される
      • 問題の対応/開放法は明確
      • 他の要素への影響はなく即時対応可能

5.2.テストの種類と内容

  • 構築側のテスト
    • 要件定義 = システムテスト(System Test: ST)
      • 要件定義書を基に、サービスに問題がないか
      • 要件定義書にかかれたユースケースのテスト
      • 要件が満たせる性能が発揮できるか、負荷テスト
    • 基本設計 = 結合テスト(Integration Testing: IT)
      • 基本設計書を基に、インフラのミドルウェア間連携やアプリのモジュール間のデータ連携を検証
      • 異常系のテストも実施
        • ジョブを途中で止めた場合など
    • 詳細設計 = 単体テスト(Unit Test: UT)
      • 詳細設計やパラメータシートを基に行う
      • 機器やサービスの起動・停止も行う
  • 運用テスト(operations test: OT)
    • 運用フローの検証
      • 実施トリガー
        • 申請がトリガーの場合、承認されるルート、内容など
        • 監視検知トリガーの場合、適切な担当者が検知するか、適切なメールがくるか
      • 担当者間をまたがるデータのやりとり
        • 担当をまたがるデータがある場合、その方法と内容を検証
      • 分岐、繰り返しの判断基準の正当性
        • 実施箇所と判断基準が誤ってないか
        • インプットデータ、アウトプットデータの整合性
    • 運用手順書の検証
      • 運用フローから呼び出される場合は、運用フローテストの項目の1つ
      • 運用項目一覧に記載してある作業がすべて実施できれば完了

おわりに

テストする事自体も大事ですが、
その後の対応や管理が雑な現場、プロジェクト、個人(自分も含めて)は多いです。

こういうところもきっちりできるようになっていきたいですね\(^o^)/

紹介

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

【設計】みんなが知っておくべき運用設計のノウハウ を読んだメモ - 4章:詳細設計フェーズ

はじめに

タイトルの通りですが、運用って意外に難しいですよね。

仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか?

  • 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...?
  • ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
  • ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ...   サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。

読んだ本

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

もくじ

  1. 詳細設計フェーズ
    • 4.1.詳細設計
    • 4.2.監視設計
    • 4.3.バックアップ設計
    • 4.4.ログ設計
    • 4.5.自動化設計

「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。

読んだ感想

この章では詳細設計における運用設計とはという形で説明されています。

運用フローや運用手順書でつまづく事が多かったために本書に手を伸ばしたこともあり、

* 「誰が」「いつ」「何をきっかけに」「何の作業を行う」
* 「手順書」や「台帳/一覧」がマッピングされてると良いフローになる

の考えは失敗体験の後に読むと非常に身にしみる章でした。

4.1.詳細設計

ソフトウェア設計では「内部設計」、「プログラム設計」を行うフェーズ。
運用設計では以下を行う

  • 運用フロー
  • 運用手順書
  • 台帳/一覧

運用フロー

  • 「誰が」「いつ」「何をきっかけに」「何の作業を行う」を記載
  • 「手順書」や「台帳/一覧」がマッピングされてると良いフローになる
  • 運用フローの種類
    • UMLアクティビティ図
      • 業務の流れを可視化する
    • BPMN(Business Process Modeling Notation)
      • ビジネスプロセスの可視化をする
  • 作成時の注意点
    • イベント発生トリガー
      • 申請なのか、障害検知か、定常作業か
    • 登場人物の情報連携方法
      • インプットとアウトプット情報を取りまとめる

運用手順書

  • 作成ポイント
    • 粒度を決めておくと良い
    • 細かすぎると手順が煩雑になる
    • 場合によってはコマンドの羅列でも良い
  • 作成者
    • 運用フローを実施するにあたって必要となる手順を記載する
    • すべての運用手順書を作ろうとしない
      • インフラ、アプリチームと分担する
    • 手順書のとりまとめ、運用担当者へ引き継ぐことが役目

台帳/一覧

  • 一覧
    • 静的データをまとめたもの
  • 台帳
    • 動的データ、定期更新があるデータ
    • IPアドレス一覧
    • サーバ構成管理票
    • ソフトウェアライセンス一覧

4.2.監視設計

監視の目的

正常に稼働しているか、停止の予兆はないかを確認し、障害時になるはやで対応できるようにしておく事

監視設計とは

  • 設計するもの
    • 監視対象
    • 監視方法
    • 監視オペレータへの通知方法
  • 監視種別
    • サービス監視
      • アクセスして正しく表示されるか
      • サービスを直接関しするため、異常検知の場合の緊急度は高い
        • HTTP監視
        • 画面遷移監視
    • インフラ監視
      • 構成要素の監視のため、サービスに影響がない場合もある
        • 冗長化されてるなど
        • ハードウェア監視
        • リソース監視
        • プロセス監視
        • ログ監視
          • error以上を監視対象
          • warnは確認する程度
  • 監視設計の勘所
    • 障害検知後に、何を基にどのように動くかを決めておく
  • 監視の運用体制
    • 営業時間内/外
    • 社内/外
  • 監視ツールの選定
  • 監視サーバの配置場所
  • 製品リモート監視サービス
  • 監視業務のアウトソース
  • 監視システムのテスト

4.3.バックアップ設計

バックアップ設計とは

  • 設計するもの
    • 取得周期
    • 取得世代
    • 復元方法
    • 前工程(基本設計)で決まっているもの
      • バックアップ対象
      • 取得先
      • バックアップ方法
  • 指標
    • RTO
      • 目標復旧時間
      • 障害が発生してから復旧までにかかる時間
    • RPO
      • 目標復旧時点
      • 障害発生時間からどのくらい前のデータに復旧できるかの時間
    • ポイント
      • 短いほどいいがコストがかかる
      • 高可用性が求められる

バックアップ種別

  • 種別
    • システムバックアップ
      • サーバOSまるごとバックアップ
      • パッチ適用時などOS領域に変更が加わる際に取得
    • データバックアップ
      • データやログ、データベースが対象
      • 取得周期はRPOと同一になる

データリカバリ

  • リストア
    • バックアップデータを復元すること
  • リカバリ
    • 障害発生直前の状態に復旧すること
    • リストア後に、必要な設定変更の実施、差分パッチを適応する

バックアップ計画

  • バックアップ方針項目
    • 目的
      • 障害/火災対策、構成変更時、など
    • バックアップ対象
      • 物理/論理、構成ファイル、DB、ログ、など
    • 取得世代数
      • 保持期間、取得回数
    • データ量
      • バックアップする総サイズ
      • バックアップ対象 x 世代数
    • 取得時間 − 取得可能な時間帯
      • バックアップウィンドという
    • バックアップ方法
      • フル、差分、増分
    • 取得媒体
      • テープ、専用ストレージ、仮想テープ装置
    • 費用
      • 初期費用、月額、追加料金

バックアップ技術

  • 重複排除
    • バックアップの冗長データを削除することでバックアップのデータ量を少なくする技術
    • データを加工して格納するので、そのままデータをバックアップするより時間がかかる
  • スナップショット
    • ストレージ内のデータや仮想環境のマシンのある瞬間をイメージとして複製すること
    • ディスク障害でデータが消えるとスナップショットも消える
    • 消去する際に負荷がかかる
    • 作成後長期間放置すると更新情報が多くなりデータ量が大きくなる
  • レプリケーション
    • 本番系のデータをリアルタイムに待機系に複製する
    • 障害発生時は自動で瞬時に待機系に切り替える事でサービスを継続する
    • RTO/RPOもほぼゼロになる
    • 本番と同じシステム構成の維持のため、費用が高い

4.4.ログ設計

ログ

  • 障害調査用
    • 障害箇所の特定や影響度の調査目的
    • 期間は短くても良い
  • 監査対応用
    • 情報流出や不正アクセスの調査目的
    • 期間は長く保存する

ログ管理サーバ

  • ログの一元管理
    • サーバや機器側での保存が必要なくなる
  • ログの分析・レポート
    • 今何が起きているか、過去に何が起きたかを確認できる
  • ログの圧縮
    • 長期間保存する場合は圧縮を行う
  • ログのモニタリング
    • リアルタイムに監視し、問題があればアラートをあげる
  • ログの原本管理、改ざん防止機能
    • 改ざんの検知

4.5.自動化設計

  • 自動化設計とは
    • 自動化に適した作業を洗い出し、どのように自動化するか検討する
    • タイミング
      • 基本設計段階
      • 運用開始後
        • 自動化の効果が出やすい
  • 自動化のメリット
    • 工数削減
    • 作業品質の向上
    • スピードアップ
    • 属人化排除
  • 運用中に自動化する時の注意点
    • 自動化の前後で作業時間を計測し効果測定する
  • 自動化対象の選定ポイント
    • 作業頻度
      • 目安は月一回以上やる作業
      • 頻度は少ないが、誰がいつやっても同じ品質を担保したいもの
    • 作業時の判断数
      • 作業時に人の判断がたくさん入る作業は向いてない事が多い
    • 作業コンポーネント数
      • 複数コンポーネントにまたがる場合も向いてない事が多い
    • 作業確実性

おわりに

エンジニアということもあり
監視ログといったシステム寄りの部分は触れる事が多いのですが、
運用フロー運用手順書となると意外にナレッジが自分に少ない!

その辺りまで考慮した進め方ができるようになれたら本当にすばらしいですね\(^o^)/

紹介

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

【設計】みんなが知っておくべき運用設計のノウハウ を読んだメモ - 3章:基本設計フェーズ

はじめに

タイトルの通りですが、運用って意外に難しいですよね。

仕事でも個人でもサービスを作りあげる事は何度もあるのに、
それでもこんな事ありませんか?

  • 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ...?
  • ローンチしちゃったから走りながら設定変える辛い...いや無理かも..
  • ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ...   サービスの開始的な言葉はローンチ/サービスイン/カットオーバーなど適宜置き換えてもらえれば

システムの運用を事前に設計するのって難しいなーと思っていたところで
この本を見かけて読んでみたので、自分用に整理したメモです。

読んだ本

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349

もくじ

  1. 基本設計フェーズ
    • 3.1.基本設計とは
    • 3.2.運用設計書記載項目

「書籍のメモ」をつづっていきますが
「自分の感想」には「※ hogehoge」という形で記載しています。

読んだ感想

この章では基本設計における運用設計とはという形で説明されています。

いわゆる基本設計自体はわかりやすいものの
基本設計時に行う運用設計とは?その書き方は?という所がとても参考になりました。

3.1.基本設計とは

基本設計は、要件定義を基にシステムの具体的な仕組みを決定する。

運用設計担当としては以下を検討する

  • 運用に必要な情報の取りまとめ
  • 運用項目書一覧
  • 各運用ごとに以下を運用設計書に記載する
    • 実施タイミング
    • いつ
    • どこで
    • 誰が
    • なにを
    • なぜ
    • どのように

役割分担を決める

インフラ・アプリチームが基本設計、運用設計チームが運用設計書を作るなど分担する。

  • 基本設計
    • 「どこで」「なにを」「どのように」がメイン
  • 運用設計
    • 「いつ」「誰が」「なぜ」がメイン

後続ドキュメントを意識する

運用設計書は、運用担当者が日々使うドキュメントを作成するためのドキュメントとなるようなものを書く。

  • 運用設計書
    • 登場人物の役割を記載した対製図
      • 運用フローを作成する上で必要
    • 運用項目一覧
      • 何の手順書を作成するかに必要
    • 運用実施タイミング
      • 台帳はいつ更新しなければならないのか
    • ※ 後続に作成する資料に何が記載されるべきかの指針になるものを記載する
  • 運用担当者が日々確認するドキュメント
    • 運用フロー
    • 手順書
    • 台帳
    • 一覧

3.2. 運用設計書記載項目

大きく分けて以下の3つ

  1. 共通項目
  2. ITILプロセス項目
  3. システム基盤項目

1. 共通項目

  • はじめに
    • 本書の目的
    • 本書の構成
    • 対象読者
  • 運用設計方針
    • システム概要
    • システム構成図
  • 運用体制
    • 運用フロー図や連絡先一覧の作成に必要
    • 関係者の役割、所属、対応時間、連絡方法、場所など
    • 作業者、承認者、確認車があればその体制
  • 業務運用
      • 人事システム運用
      • 経理システム運用
      • Web予約システム運用
  • 保守運用
  • システムのライフサイクル
  • 運用項目書一覧
    • サービスカタログと混同されがちだが別物
    • サービスカタログは利用者に提供するサービス一覧
    • 運用項目書は、サービスを提供するシステム運用の定常作業、臨時作業の一覧
    • 以下が書かれる
      • 作業名
      • 作業概要
      • 発生頻度
      • 実施者

2. ITILプロセス項目

  • インシデント管理
    • どこか1つに集めるシングルポイントを作ると管理がうまくいく
    • 各運用ごとにちらばってると分析できない
  • 問題管理
    • インシデントの中で解決が必要なものを問題管理として扱う
    • 費用対効果を基に解決するかどうかを判断する箇所を作る
  • 変更管理/リリース管理
    • システムの計画、手順、設計、運用を変更する場合のるs句、作業の正当性を管理する
    • きちんとやるには高コスト
    • リリース種別を決めて、種別ごととで管理基準をつける
  • 構成管理(サービス資産管理)
    • CI(Configuration Item)とその管理方法について記載
    • 対象
      • ハードウェア
      • ネットワーク
      • PC
      • ソフトウェア
    • 問題点は「担当者が気を抜くと更新を忘れる」項目
      • 鉄の掟を作る
      • ツールを駆使して更新漏れをなくす
  • 情報セキュリティ管理
    • セキュリティ対策など
  • サービスレベル管理(SLA)
    • どの程度の品質を保証するかの合意
      • 運用が止まる = サービスが止まる
    • SLA違反をしたら罰則があるのか、何があるのか、努力目標か、必須達成目標か
  • 可用性管理
    • 稼働率
    • オンライン時間
    • 定期メンテ時間
  • 拡張計画
    • リソース枯渇に対する拡張計画
  • サービス測定/サービスレポート
    • 報告すべき内容を検討・合意する

3. システム基盤項目

インフラチームと連携して作る運用設計書

  • 監視
  • ジョブ管理
    • 自動化している作業の一覧や概要
  • バックアップ・リスト運用
    • バックアップ方針、対象、リストアトリガー
  • ログ管理
    • 障害調査用、監査用

運用項目一覧を合意する

運用のランニングコストを概算することができる

  • 定常作業はどのくらいあるか、何時間くらいかかるか
  • データセンターにかけつける作業はあるか、どのくらいの頻度か
  • ※ 年間で運用に必要な工数と運尿担当者のスキルセットが見える

おわりに

どう書くのが良いんだろう、と悩む事は多いので
運用設計書記載項目 のようにまとまっているのはとても参考になりますね!

現場ごとのドキュメントの書き方ガイドラインとか作ると良さそうです\(^o^)/

紹介

みんなが知っておくべき運用設計のノウハウ
(2017-10-30)
売り上げランキング: 349