Merge pull request #25 from PagerDuty/formatting

Fix format, typo and wording

Author: pd-mhori

docs/before/complex_incidents.md

@@ -1,8 +1,8 @@
 ---
 cover: assets/img/covers/complex_incidents.png
-description: やがて、あなたも多くのリソースに影響が広がるインシデント（あるいは同時多発インシデント）に関わるときが訪れるでしょう。そのような場合に備えて、関係者を効果的なコントロール範囲に置くことが大切です。このページでは、そのようなインシデントをマネジメントする方法を紹介します。
+description: やがて、あなたにも多くのリソースに影響が広がるインシデント（あるいは同時多発インシデント）に関わるときが訪れるでしょう。そのような場合に備えて、関係者を効果的なコントロール範囲に置くことが大切です。このページでは、そのようなインシデントをマネジメントする方法を紹介します。
 ---
-やがて、あなたも多くのリソースに影響が広がるインシデント（あるいは同時多発インシデント）に関わるときが訪れるでしょう。そのような場合に備えて、関係者を効果的な[コントロール範囲](../training/glossary.md#span-of-control)に置くことが大切です。このページでは、そのようなインシデントをマネジメントする方法を紹介します。
+やがて、あなたにも多くのリソースに影響が広がるインシデント（あるいは同時多発インシデント）に関わるときが訪れるでしょう。そのような場合に備えて、関係者を効果的な[コントロール範囲](../training/glossary.md#span-of-control)に置くことが大切です。このページでは、そのようなインシデントをマネジメントする方法を紹介します。
 
 ## 複雑なインシデントの特定
 

docs/before/different_roles.md

@@ -11,7 +11,7 @@ PagerDutyのインシデント対応チームには、いくつかの主要な
 また、大規模で複雑なインシデントにおいては、サブチームの形成を考慮したロール構造の調整が生じるかもしれません。複雑なインシデントへの対処については [複雑なインシデント](../before/complex_incidents.md) を参照してください。
 
 !!! tip "柔軟な構造を考える"
-     個々のインシデントにおいては、各ロールに毎回異なる人が割り当てられることが意図されているわけではありません。例えばインシデントのスコープが十分に小さい場合には、副指揮官（Duputy）が、書記官（Scribe）や内部向け連絡係（Internal Liaison、以降インターナルリエゾン）を兼任することもありえます。構造は柔軟に、インシデントの規模やスコープに応じて変更するとよいでしょう。
+     個々のインシデントにおいては、各ロールに毎回異なる人が割り当てられることが意図されているわけではありません。例えばインシデントのスコープが十分に小さい場合には、副指揮官（Deputy）が、書記官（Scribe）や内部向け連絡係（Internal Liaison、以降インターナルリエゾン）を兼任することもありえます。構造は柔軟に、インシデントの規模やスコープに応じて変更するとよいでしょう。
 ---
 
 ## インシデントコマンダー (IC)

docs/before/severity_levels.md

@@ -1,19 +1,19 @@
 ---
 cover: assets/img/covers/severity_levels.png
-description: インシデントは深刻度や優先度によって分類されます。PagerDutyにおいては「SEV」のレベルを用いて、小さな数字の深刻度であるほど緊急性の高いものであるとみなします。運用上の問題はこれらの深刻度のレベルによって分類でき、一般的には深刻度の高い問題であるほど、解決するためならばリスクの高いアクションを取れます。
+description: インシデントは重大度や優先度によって分類されます。PagerDutyにおいては「SEV」のレベルを用いて、小さな数字の重大度であるほど緊急性の高いものであるとみなします。運用上の問題はこれらの重大度のレベルによって分類でき、一般的には重大度の高い問題であるほど、解決するためならばリスクの高いアクションを取れます。
 ---
-インシデント対応の最初のステップは、実際に [インシデントがなにから構成されるのか](../before/what_is_an_incident.md) を定めることです。インシデントは、通常「SEV」の定義を用いた深刻度（Serverity）によって分類され、数字の小さな深刻度であるほど緊急性の高いものとされます。運用上の問題はこれらの深刻度のレベルによって分類でき、一般的には深刻度の高い問題であるほど、解決するためならばリスクの高いアクションを取れます。SEV-3よりも高い深刻度のものは自動的に「重大インシデント」と考えられ、通常のインシデントよりも集中した対応が行われます。
+インシデント対応の最初のステップは、実際に [インシデントがなにから構成されるのか](../before/what_is_an_incident.md) を定めることです。インシデントは、通常「SEV」の定義を用いた重大度（Serverity）によって分類され、数字の小さな重大度であるほど緊急性の高いものとされます。運用上の問題はこれらの重大度のレベルによって分類でき、一般的には重大度の高い問題であるほど、解決するためならばリスクの高いアクションを取れます。SEV-3よりも高い重大度のものは自動的に「重大インシデント」と考えられ、通常のインシデントよりも集中した対応が行われます。
 
 !!! tip "常に最悪のケースを想定すること"
-     インシデントの深刻度の判断がつかないとき（SEV-2にすべきかSEV-1にすべきかなど）は、 **高いほうの深刻度のものとして扱いましょう**。インシデント発生中は深刻度を議論したり争ったりしている場合ではなく、いったんその時点で最も高い深刻度を想定しておき、ポストモーテムの際にレビューすればよいのです。 
+     インシデントの重大度の判断がつかないとき（SEV-2にすべきかSEV-1にすべきかなど）は、 **高いほうの重大度のものとして扱いましょう**。インシデント発生中は重大度を議論したり争ったりしている場合ではなく、いったんその時点で最も高い重大度を想定しておき、ポストモーテムの際にレビューすればよいのです。 
 
 !!! question "SEV-3は重大インシデントになりうるか？"
-     すべてのSEV-2は重大インシデントですが、すべての重大インシデントがSEV-2である必要はありません。たとえ低い深刻度の問題であっても、協調的な対応が必要なのであれば、インシデント対応プロセスを開始しましょう。完全形のインシデント対応が必要とされるかどうか、インシデントコマンダーが判断できるでしょう。
+     すべてのSEV-2は重大インシデントですが、すべての重大インシデントがSEV-2である必要はありません。たとえ低い重大度の問題であっても、協調的な対応が必要なのであれば、インシデント対応プロセスを開始しましょう。完全形のインシデント対応が必要とされるかどうか、インシデントコマンダーが判断できるでしょう。
 
 <table class="custom-table">
   <thead>
     <tr>
-      <th class="sev">深刻度（Severity）</th>
+      <th class="sev">重大度（Severity）</th>
       <th>内容</th>
       <th>一般的な対応</th>
     </tr>
@@ -121,4 +121,4 @@ description: インシデントは深刻度や優先度によって分類され
 </table>
 
 !!! note "具体的にすることが大事"
-    これらの深刻度の定義は、PagerDutyの内部的な定義をより一般化したものです。あなた自身のドキュメンテーションにおいては、影響を受けたユーザーや顧客数など、きわめて具体的な定義にすることをお勧めします。深刻度は通常、指標に基づいて判断できるように定義したいものです。
+    これらの重大度の定義は、PagerDutyの内部的な定義をより一般化したものです。あなた自身のドキュメンテーションにおいては、影響を受けたユーザーや顧客数など、きわめて具体的な定義にすることをお勧めします。重大度は通常、指標に基づいて判断できるように定義したいものです。

docs/before/what_is_an_incident.md

@@ -1,7 +1,6 @@
 ---
 cover: assets/img/covers/incident.png
-description: 
-インシデント対応プロセスを定義する前に、インシデント（そして重大インシデント）とは何か、対応の開始方法とともに定義する必要があります。
+description: インシデント対応プロセスを定義する前に、インシデント（そして重大インシデント）とは何か、対応の開始方法とともに定義する必要があります。
 ---
 インシデント対応プロセスを定義する前に、インシデント（そして重大インシデント）とは何かを定義する必要があります。
 
@@ -35,11 +34,11 @@ description:
 !!! question "対応が必要か？"
     もし対応が必要なのかはっきりしない場合には、インシデント対応プロセスを開始してください。プロセスの開始に必要なのは、Slackに `!ic page` と打って、インシデントコマンダーに通知を送ることだけです。
 
-## インシデントの深刻度
+## インシデントの重大度
 
-私たちの [深刻度の定義](../before/severity_levels.md) では、あらかじめ定義されたガイドラインに基づき、私たちが個々のインシデントをどのくらい深刻であると _考えるか_ を定めたものです。この狙いは、対応者がどのような対応を取れるのかを判断できるようにすることです。例えば、深刻度が高いほど、システムを正常に戻すためならばリスクの高い決定を下せるのです。
+私たちの [重大度の定義](../before/severity_levels.md) では、あらかじめ定義されたガイドラインに基づき、私たちが個々のインシデントをどのくらい深刻であると _考えるか_ を定めたものです。この狙いは、対応者がどのような対応を取れるのかを判断できるようにすることです。例えば、重大度が高いほど、システムを正常に戻すためならばリスクの高い決定を下せるのです。
 
-深刻度は、より複雑な対応が必要になるかどうかや、そもそも連携の取れた対応が必要なのかどうかを素早く判断するのに有用です。しかしながら、なにをもって重大インシデントとするのかを明確に白黒で判断できるような定義はありません。もし、私たちの深刻度の定義でカバーできていないものがあったとして、あなたがインシデント対応が必要だと考えるならば、インシデント対応が必要なのです。私たちが知る必要があるのは、それが果たして重大インシデントなのかどうかだけです。深刻度のレベルはあとで決めればよく、インシデント対応プロセスの開始に必須のものではありません。
+重大度は、より複雑な対応が必要になるかどうかや、そもそも連携の取れた対応が必要なのかどうかを素早く判断するのに有用です。しかしながら、なにをもって重大インシデントとするのかを明確に白黒で判断できるような定義はありません。もし、私たちの重大度の定義でカバーできていないものがあったとして、あなたがインシデント対応が必要だと考えるならば、インシデント対応が必要なのです。私たちが知る必要があるのは、それが果たして重大インシデントなのかどうかだけです。重大度のレベルはあとで決めればよく、インシデント対応プロセスの開始に必須のものではありません。
 
 ## メンタリティの転換