# Playbook: Playbook /Runbook の作成プロセス このドキュメントは、情報提供のみを目的として提供されています。 本書は、このドキュメントの発行日時点におけるAmazon ウェブサービス (AWS) の現在の製品提供および慣行を表しており、これらは予告なしに変更される場合があります。 お客様は、本書に記載されている情報、および AWS 製品またはサービスの使用について、独自の評価を行う責任を負うものとします。各製品またはサービスは、明示または黙示を問わず、いかなる種類の保証もなく「現状のまま」提供されます。 このドキュメントは、AWS、その関連会社、サプライヤー、またはライセンサーからの保証、表明、契約上の約束、条件、または保証を作成するものではありません。 お客様に対する AWS の責任と責任は、AWS 契約によって管理され、このドキュメントは AWS とお客様との間のいかなる契約の一部でもなく、変更もありません。 © 2021 Amazon ウェブサービス, Inc. またはその関連会社。 すべての権利予約。 この作品はクリエイティブ・コモンズ表示 4.0 国際ライセンスの下に提供されています。 この AWS コンテンツは、http://aws.amazon.com/agreement で提供される AWS カスタマーアグリーメントの条件、またはお客様とアマゾンウェブサービス株式会社、Amazon ウェブサービス EMEA SARL、またはその両方との間のその他の書面による契約に従って提供されます。 ## 連絡ポイント 著者:`著者名`\ 承認者:`承認者名`\ 最終承認日:2021年3月25日 ## NIST 800-61r2 フェーズ 準備 ## エグゼクティブ・サマリー このプレイブックでは、GitLab を使用して新しいプレイブック/ランブックを作成し、ドキュメントをドラフトから承認済みに移行するプロセス、および再検証要件の概要を説明します。 より高度なプレイブックの作成については、[AWS インシデントレスポンス Playbooks ワークショップ] (https://gitlab.aws.dev/fredski/aws-incident-response-playbooks-workshop/-/blob/main/playbooks/crypto_mining/EC2_crypto_mining.md) を参照してください。 ## ガイダンス > Runbooks を深く掘り下げ、結果を迅速に顧客に提供できるように維持することが重要です。 Matthew Helmke Per「Runbooksは、信頼性を構築するために設計された幅広いプラクティスの一環として私たちを助けてくれます。 Runbooks を最新の状態に保つことは、サイト信頼性エンジニアリングにおいて重要な部分です。」 (< https://www.gremlin.com/blog/ensuring-runbooks-are-up-to-date/ >) 私たちのチームは Github を使ってドキュメントを管理しています。 [参考文献] (.. /Playbook_Creation_Process.md/ #references) を使用して、プロセスフローの省略された手順を参照してください。 ## 新しいプレイブック/Runbook ### GUI プロシージャ * プロセストラッキング用の課題を作成する * 作業する新しいソースブランチを作成する * ブランチのルートに移動する *「Web IDE」ボタンを選択 * アイテムを作成するには、左マージンのフォルダを強調表示し、オプションのドロップダウン矢印を選択します *「新規ファイル」を選択 * 注:書式設定のために既存の Playbook からコンテンツをコピーすると便利な場合があります * 私たちのドキュメントは [GitHub Flavored Markdown] (https://github.github.com/gfm/) * ライブラリの標準命名規則に従っていることを確認してください * Playbooks: `# Playbook: Playbook/Runbook` * ツールガイド:`# ツーリング:ToolName` * ドキュメント内で Header 1 (H1) が使用されるのはこれだけです * 関連する課題へのリンクを作成する * 例:`課題を関連付ける:(. /issue/1) ` * ドキュメントが完成したら: * 課題内のドキュメントへのリンクをコメントとして追加する * 問題に「REVIEW」というラベルを付けて *「顧客対応方法」に課題へのリンクを記載したメッセージを投稿し、レビュー/コメントをリクエストします。 * Playbook を承認するには、少なくとも 2 人のチームメンバーが、関連する課題に自分の名前とコメントをレビューし、追加している必要があります * ドキュメントに対する推奨事項や修正を更新して実施する * 文書が審査され、すべての修正が行われたら、承認プロセスを確定するために文書を提出してください。 * 課題に入り、担当者を承認者に変更する * 問題に入る * 承認のために提出されたラベルを課題に追加する *「担当者」の横の右余白で「編集」を選択 * 担当者を`承認者` に変更する * ドキュメントが最終審査の準備ができていることを知らせるメモを「承認者」に送信する * 承認後、ドキュメント/プレイブックへのリンクを Readme に追加します * 例:`[プレイブック作成プロセス] (. /docs/Playbook_Creation_process.md) ` * マージリクエストを送信する * 注:マージリクエストの前にあるすべてのステップは、作業中のブランチ内で完了する必要があります。 * このタスクの SLA は、ドキュメントを送信した時点から 7 暦日です。 * 承認のためにSLA期間内に返信が届かない場合は、`ユーザーA`、`ユーザーB`、`ユーザーC`にチャイムノートを送信してエスカレートしてください。 ### CLI プロシージャ 未定 ## Playbook/Runbook のアップデート ### 手順 * プロセストラッキング用の課題を作成する * 作業する新しいソースブランチを作成する * ブランチのルートに移動する *「Web IDE」ボタンを選択 * 新しい課題を開いて、変更の進捗状況を追跡する * 既存のラベルをすべて削除する * DRAFTというラベルを追加 * 関連する課題へのリンクを作成する * 課題をリストに追加できます * 例:(issue1), (issue1), (issue3) * ドキュメントが完成したら: * 課題内のドキュメントへのリンクをコメントとして追加する * 問題に「REVIEW」というラベルを付けて *「顧客対応メカニズム」に課題へのリンクを記載したメッセージを投稿し、レビュー/コメントをリクエストする。 * Playbook を承認するには、少なくとも 2 人のチームメンバーが、関連する課題に自分の名前とコメントをレビューし、追加している必要があります * ドキュメントに対する推奨事項や修正を更新して実施する * 文書が審査され、すべての修正が行われたら、承認プロセスを確定するために文書を提出してください。 * 課題に入り、担当者を承認者に変更する * 問題に入る * 承認のために提出されたラベルを課題に追加する *「担当者」の横の右余白で「編集」を選択 * 担当者を`承認者` に変更する * Chime で「承認者」にメモを送って、ドキュメントが最終審査の準備ができていることを知らせる * 承認後、ドキュメント/プレイブックへのリンクを Readme に追加します * 例:`[プレイブック作成プロセス] (. /docs/Playbook_Creation_process.md) ` * マージリクエストを送信する * 注:マージリクエストの前にあるすべてのステップは、作業中のブランチ内で完了する必要があります。 * このタスクの SLA は、ドキュメントを送信した時点から 7 暦日です。 * 承認のためにSLA期間内に返信が届かない場合は、`ユーザーA`、`ユーザーB`、`ユーザーC`にメモを送信してエスカレートしてください ### CLI プロシージャ 未定 ## 承認プロセス ### タスクオーナー: チームオーナー ### サービスレベルアグリーメント -著者提出から7暦日 ### 手順 * GitHub でドキュメントと関連する問題をレビューする * ドキュメントのタイトルから REVIEW を削除 * ドキュメントから「THIS A A DRAFT PLAYBOOK」という文を削除してください * 連絡先の下に -承認者に名前を追加/更新する -ドキュメントの承認時に「最終承認日」をYYYYY/MM/DDとして追加/更新する * 課題をリクエスタに再割り当てする * プレイブックが承認されたというコメントを課題に追加し、マージリクエストを続行する ## 参考文献 ### GitHub を使う:課題を作成する 課題を使用して、進行中および完了した作業を追跡します。 さらに、これにより、チームのレビューと承認プロセスを通じて移行できます。 これにより、レビュアーからのコメントは、ドキュメントバーレイザープロセスの一環として、リポジトリオブジェクト内のあらゆるものに対処できます。 * グラフィカルユーザーインターフェイス:GUI を使用すると、ウェブブラウザから GitHub と対話して、このリポジトリと対話できます。 1. お気に入りのウェブブラウザを使用して GitHub リポジトリに移動する 1. トップメニューから [課題] を選択して、課題を開きます。 1. 「新しい問題」を選択します。 1. 作業中の内容のタイトルと説明を追加する 1. 自分に割り当てる (これにより、後の手順で追跡できるようになります) 1. マイルストーンについては、「お客様のマイルストーン」を選択します。 1. [ラベル] で、課題に適したものを選択します。 * 新しいドキュメントの場合は、[ドラフト] を選択してください 1. 「課題を送信」を選択します。 1. 新しい課題ページの右マージンで、課題のロック > 編集 > ロック * コマンドラインインターフェイス:CLI を使用すると、コマンドラインから GitHub と対話できます ### GitHub を使う:ブランチを作成して作業する 私たちは個々のブランチで働いているので、進行中の作業は、他の人がリアルタイムで行っている可能性を妨げることはありません。 * グラフィカルユーザーインターフェイス:GUI を使用すると、[WebブラウザからGitHub を使ってこのリポジトリと対話できる] (https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository) * コマンドラインインターフェイス:CLI を使用すると、コマンドラインから GitHub と対話できます ### GitHub を使う:マージリクエストを作成する マージリクエストでは、親リポジトリとマージする前に、セカンダリバーレイザーのレビューを許可します。 * [グラフィカルユーザーインターフェイス] (https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges) * コマンドラインインターフェイス:CLI を使用すると、コマンドラインから GitHub と対話できます ## バックログアイテム