運用設計書 テンプレート。 【社内資料公開】運用手順書を作る時のポイントについて書いてみた

【社内資料公開】運用手順書を作る時のポイントについて書いてみた

運用設計書 テンプレート

単体テスト 結合テスト 機能テスト システムテスト(負荷テスト、ボリュームテスト、セキュリティテスト etc 受け入れテスト(シナリオテスト) 運用テスト リグレッションテスト 現場によっては、 「開発エンジニア」がテストしたり、また 「QAエンジニア」がテストしたりと異なります。 私の意見としては、 「開発エンジニア」と 「QA担当者」が確認すべきではないかと。 単体テストの実施は、 開発者が担当します。 また、 結合テスト以降のテストは QAエンジニア、もしくはQAテスターが担当する。 単体テストのルールや 網羅性は開発とQAが一緒に考えることが品質を良くする上で大事です。 お互いテストの意義というものを見直すこともできます。 また、仕様を理解している企画や開発者。 テスト設計やテストの種類を知っているテスト担当者が協力しあうことが品質を高めるのではないでしょうか。 特にスタートアップでは、要件機能仕様書も無いので。 コミュニケーションという点では。 テスト仕様書を作成しテストケースを用意する 「テスト計画」、「テスト設計」をし、「テスト仕様書」を作成します。 もちろん、「レビュー」も必要となりますので、見積には追加。 テスト工程は、テスト工程のケースのみチェックする。 何を担保しているテストケースかわからなくなり 工数を増やす要因となる。 各部署との確認を明確化する。 無いからわかりません。 やりませんでしたと無いように、テスト準備段階で確認する。 ・無駄なケースが無いか確認する。 直交表やAllpair法を使用し、必要なケースのみ。 ・前提条件を必ず記載していること。 レビュー者の負担もある。 ・大項目、中項目、小項目、前提条件、操作方法は、わかりやすく。 「単体テスト」、「結合テスト」、「システムテスト」 テスト自動化だけでは難しいので箇所によっては、やはり手動になってしまう。 開発用テストケースです。 設計書の動作だけではなく、設計書に記載していない箇所もテストケースに入れます。 あとは、Webブラウザ単位にテスト。 バージョン単位にテスト。 想定は、WEB系のQAチームになります。 ナレッジはありますが、開発者との距離が離れてしまう懸念もあります。 しかし、開発者では気がつかない不具合を検出するには良いと思います。 テストデータ問題がある。 どれだけ用意したらいいのか。 ここは難しいですね。 どういう方法で作成すれば?? 1. テストデータツールを使用 PICT(Pairwise Independent Combinatorial Testing tool) Excelプラグインツールに「PictMaster」 テスト設計例 テスト仕様書に落とし込むまでの設計作成例です。 テスト仕様書を全てレビュー、例えば数千件のテストケースをレビューするのかというと現実的ではありません。 今回は例として「氏名」・「電話番号」・「住所」の設計となります。 確認項目は、下記の確認項目に紐づけテスト仕様書を作成する形となります。 カラムの追加がある場合は確認。 またテストデータ更新、追加した場合の値の確認。 logに出力。 テスターにわかりやすいように、テスト詳細や、前提条件などを用意。 重要度「高」「中」「低」やテスト区分「正常系」「異常系」も設定します。 テスターは、期待値が実測値とあっているかを確認し、テスト結果をプルダウンから選択 「OK」 「NG」 「PN」を作成。 また、不具合管理票にも記載しましょう。 「OK」は、期待値と実測値が同じである 「NG」は、期待値と実測値が異なっている 「PN」は、テスト環境不備やテストケース自体実行できない場合 4. バグ検出率や、テストケース消化率を算出できるように。 ここはExcel関数を使用して集計を楽にしましょう。 テストデータ 2. テスト環境の確認 DBに接続できる、対象のテーブルがある、phpのバージョンが正しい トップシート ここで各シートの計算を表示しています 1. テストケース件数 2. テスト消化件数 3. バグ検出率 4. テスト消化率 テストシート テスト仕様書のテンプレート化 案件、その都度作成しては、作成工数やレビュー工数が膨れ上がってしまいます。 そのため、全体の機能のテンプレートを進めることにより作成者依存がなくなり、品質の偏りもなくなります。 不具合の記載 テストケースには、テスト結果項目でNGを選択。 再現手順をバグ管理システムに登録する。 一般的には、JiraやRedmineが使われることが多い。 Backlogも。

次の

基本設計書サンプル・書き方

運用設計書 テンプレート

はじめに こんにちは植木和樹@上越妙高オフィスです。 本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者• 開発・構築したシステムを別の人に引き継ぐ予定のある人• 他の人が作ったシステムを引き継ぐ担当の人• 半年後の自分でも分かる手順書の書き方に困っている人 (この記事を読むのにかかる時間の目安:5分) 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。 見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 特に必要スキルについては簡単でも良いので書いておくと良いです。 AWSマネージメントコンソールでEC2の操作ができること• ansible-playbookを使った構成変更ができること 開発者(ドキュメント作成者)の立場からすると、作業する人のスキルがどの程度なのか分からないと、どこまで詳細に書いたらいいものか悩んでしまいます。 そこで「最低限この辺のスキルができる人を対象にしてますよー」というのを示しておくと手順も必要以上に冗長にならず良いです。 クラスメソッドのオペレーションチームでは標準スキルセットを定めてます(社内試験がある)ので、知りたい人はお声かけください。 作業環境について書く いきなり「管理画面にログインして〜」と書かれても困ってしまいます。 操作環境について書いておきましょう。 AWSアカウントID• 管理画面URL• Beanstalk アプリケーション名• 構成図を貼り付ける 見知らぬシステムを任されるのは怖いものです。 システム構成図が1枚あるだけで「なるほど、こういう構成になってるのか」と安心できます。 典型的な構成としては以下のものでしょうか。 EC2あたりは要素の横に、動いているアプリケーション ApacheとかTomcatとか が書いてあると尚良いです。 ELB• EC2 AutoScaling? Opsworks? Beanstalk? ElastiCache memcached or redis• RDS MySQL? PostgreSQL? Oracle? SQLServer? 個別作業手順ごとに書くこと 次に個々の詳細手順に書いておいてもらいたいことです。 作業にかかる目安時間を書く 作業にかかる目安時間があるとうれしいです。 30分くらいで終わる作業なのか、4時間かかる作業なのか。 目安時間がわかると作業日程調整時の参考になりますので。 いつ、それをするのか?を書く いきなり「サーバーリブート手順」とだけあるのではなく、どんな時にその手順を実施するのか書いておいてください。 ストーリーがあると理解しやすくなります。 障害発生時• 作業依頼がきた時(不定期)• 作業手順の書き方 実際の作業手順は好きに書いてもらって良いです。 最終的にはレビューして不足は修正していきますので。 前述した「想定するスキルレベル」の人が分かるように書くようにしましょう。 分かりづらい言い回しが修正されたり、作業者視点でのメモや注意箇所などが書き込まれたりしてどんどんブラッシュアップされていくものです。 まずは作業メモレベルで良いのです。 確認手順を書く 作業手順だけが書かれていて、確認手順が記載されていないことが多いです。 作業が正しくできているのか確認する手順も記載してください。 ELBのステータスがInServiceになっていること• BeanstalkのステータスがGreenになっていること• 作成したユーザーでXXXXという操作ができること• ブラウザで XXXXX へアクセスして画面が表示できること 3. エスカレーション先を書く 不幸なことに手順書通りに進めてもうまくいかないことがあります。 また手順書に記載されていない作業が求められることもあるでしょう。 特に想定外の障害が発生した場合には開発(保守)チームにエスカレーションすることになります。 ただ「想定外のことがあったら開発チームに緊急エスカレーションしてください」だけではどうしたらいいか分かりません。 連絡手段を書く エスカレーションの手段を書いておきましょう。 メーリングリスト• Backlog• Chatwork 3. 宛先を書く 開発チームの宛先を書いておきましょう。 メールアドレス• Backlogのプロジェクト名とアサインする担当者• Chatworkの部屋(メンションする人がいれば担当者名) おまけ:個人的な趣向 これ以降はとても個人的な意見です。 版数はつける?どうつける? 版数はつけてほしいです。 手順書がファイル(WordやExcel! )に記載されているなら必須です。 手順書がWikiなどオンラインで参照するなら、常に最新版であることが保証されるのでなくてもいいです。 (たまに印刷してる人いますけど) 版数はv1. 0とかでなく、更新日付(v20160629とか)が一番わかりやすい。 ドキュメントの分割 細かくドキュメントを分割されるより、すべての手順が1ページにまとまっててくれた方がうれしいです。 そのシステムに関する手順が見たければ、とにかくそのページ(ファイル)を開けば良いからです。 ページを開いた後に、目次やページ内検索で探すのが一番ヒット率が高い気がします。 細かくページやファイルが分割されている場合は、分かりやすい構成になっていないと探したい情報に辿りつけない事が多いです。 目次で作業ステップが分かるようにする 目次を読むだけで、どんな作業をするのか分かるようになっているとうれしいです。 例えば障害のあったEC2を復旧させる手順について書く場合にはこんな感じでしょうか。 Webサーバーステータス障害時の復旧手順(作業目安: 10分) 1. 障害の発生しているサーバーのインスタンスIDを確認する 1. サーバーをTerminateする 1. AutoScalingで新しいサーバーが起動するまで待つ 1. ELBでInServiceになっていることを確認する ドキュメントの置き場所 開発者はシステム単位で仕事をするため下記のようなディレクトリ構成にすることが多いですよね。 最近はページにタグ付けできるWikiが使えますので、ドキュメントはWikiにまとめて「手順書」タグをつけるとか、手順書一覧ページからリンクを貼るのがベストだと思ってます。 もしくはBacklogやRedmineのようにプロジェクト毎にファイル置き場があって、ドキュメントはそこにまとめる(で、ポインタだけ集中管理する)、でもいいと思います。 まとめ 運用業務はシステム横断的な業務であるという点と、3〜5年(長いと10年)という中長期に渡ってモノ(手順書)を管理するという点があるため、なかなか全社で1つのやり方に決めることが難しかったりします。 ルールを1つに決めると「オレはそのやり方気に入らない」「最近はこのやり方が流行り」という意見がでますので、時代時代にあわせて何パターンかの管理方法を決めて運用するという妥協も必要だと思ってます。 運用手順書を書く上で大切なのは• 開発者がドキュメントを書く(心理的)敷居を低くする• ドキュメントは単発ものでなく、徐々に育てる• 開発者と運用者が歩みよってよいものにしていく• 最新版は常に1つに保つ(最重要!) じゃないでしょうか。 ということで、社内のとある人から質問を受けたのでアンサーブログを書いてみました。 運用手順書を書く際、レビューする際のチェックリスト的に参考になれば幸いです。

次の

機能一覧

運用設計書 テンプレート

はじめに タイトルの通りですが、運用って意外に難しいですよね。 仕事でも個人でもサービスを作りあげる事は何度もあるのに、 それでもこんな事ありませんか?• 必死で没頭して熱中してローンチしたら、あれこれ運用するのどうするんだ... ローンチしちゃったから走りながら設定変える辛い... いや無理かも.. ローンチしたはいいけどデータの更新とか誰がどうやってやるんだ... 読んだ本 もくじ• 基本設計フェーズ• 基本設計とは• 読んだ感想 この章では基本設計における運用設計とはという形で説明されています。 いわゆる基本設計自体はわかりやすいものの 基本設計時に行う運用設計とは?その書き方は?という所がとても参考になりました。 基本設計とは 基本設計は、要件定義を基にシステムの具体的な仕組みを決定する。 運用設計担当としては以下を検討する• 運用に必要な情報の取りまとめ• 運用項目書一覧• 各運用ごとに以下を運用設計書に記載する• 実施タイミング• どこで• なにを• どのように 役割分担を決める インフラ・アプリチームが基本設計、運用設計チームが運用設計書を作るなど分担する。 基本設計• 「どこで」「なにを」「どのように」がメイン• 運用設計• 「いつ」「誰が」「なぜ」がメイン 後続ドキュメントを意識する 運用設計書は、運用担当者が日々使うドキュメントを作成するためのドキュメントとなるようなものを書く。 運用設計書• 登場人物の役割を記載した対製図• 運用フローを作成する上で必要• 運用項目一覧• 何の手順書を作成するかに必要• 運用実施タイミング• 台帳はいつ更新しなければならないのか• 運用担当者が日々確認するドキュメント• 運用フロー• 手順書• 一覧 3. 運用設計書記載項目 大きく分けて以下の3つ• 共通項目• ITILプロセス項目• システム基盤項目 1. 共通項目• はじめに• 本書の目的• 本書の構成• 対象読者• 運用設計方針• システム概要• システム構成図• 運用体制• 運用フロー図や連絡先一覧の作成に必要• 関係者の役割、所属、対応時間、連絡方法、場所など• 作業者、承認者、確認車があればその体制• 業務運用• 人事システム運用• 経理システム運用• Web予約システム運用• 保守運用• システムのライフサイクル• 運用項目書一覧• サービスカタログと混同されがちだが別物• サービスカタログは利用者に提供するサービス一覧• 運用項目書は、サービスを提供するシステム運用の定常作業、臨時作業の一覧• 以下が書かれる• 作業名• 作業概要• 発生頻度• 実施者 2. ITILプロセス項目• インシデント管理• どこか1つに集めるシングルポイントを作ると管理がうまくいく• 各運用ごとにちらばってると分析できない• 問題管理• インシデントの中で解決が必要なものを問題管理として扱う• 費用対効果を基に解決するかどうかを判断する箇所を作る• システムの計画、手順、設計、運用を変更する場合のるs句、作業の正当性を管理する• きちんとやるには高コスト• リリース種別を決めて、種別ごととで管理基準をつける• 構成管理(サービス資産管理)• CI(Configuration Item)とその管理方法について記載• ハードウェア• ネットワーク• ソフトウェア• 問題点は「担当者が気を抜くと更新を忘れる」項目• 鉄の掟を作る• ツールを駆使して更新漏れをなくす• 情報セキュリティ管理• セキュリティ対策など• サービスレベル管理(SLA)• どの程度の品質を保証するかの合意• SLA違反をしたら罰則があるのか、何があるのか、努力目標か、必須達成目標か• 可用性管理• 稼働率• オンライン時間• 定期メンテ時間• 拡張計画• リソース枯渇に対する拡張計画• 報告すべき内容を検討・合意する 3. システム基盤項目 インフラチームと連携して作る運用設計書• ジョブ管理• 自動化している作業の一覧や概要• バックアップ・リスト運用• バックアップ方針、対象、リストアトリガー• ログ管理• 障害調査用、監査用 運用項目一覧を合意する 運用のランニングコストを概算することができる• 定常作業はどのくらいあるか、何時間くらいかかるか• データセンターにかけつける作業はあるか、どのくらいの頻度か•

次の