AWSクラウド活⽤の 強⼒な味⽅ AWSサポートの使い⽅ 2024/7/16 Classmethod, Inc. George Yoshida(@quiver)

Xへの投稿の際は、 ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い

⾃⼰紹介 ● 名前 : George Yoshida ● Blog : https://dev.classmethod.jp/author/quiver/ ● 仕事 : ○ AWS事業本部モダンアプリコンサルティングチーム ○ ex-⽇本深夜帯のエスカレーション対応 ● 所属 : HND󰏦 → TXL/BER󰎲 → FUK󰏦 ● 2024 Japan APN AWS ○ Top Engineer(Database) ○ All Certifications Engineer 3

AWSサポート 使っていますか? 4

⽇々湧き上がるAWSのギモン ● 利⽤費の試算 ○ S3ストレージの料⾦計算⽅法 ● トラブルシュート ○ EC2にSSHできない ● 仕様確認 ○ 複数のIAMポリシーの評価順 5

AWSサポートが これら課題を⽀援 6

東京リージョン開設時からサポート提供 7 https://aws.amazon.com/jp/about-aws/whats-new/2011/03/02/announcing-asia-pacific-tokyo-region/

問い合わせのガイドラインが存在 8 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

ガイドラインは早期解決のため ● 対応の優先度付け ● 適切な担当者の割り当て ● 正確な障害対応‧問題の再現 9

10 1. 起票前にもう⼀度調べてみよう 2. 2種類の窓⼝を使い分ける 3. 解決の定義を明確に 4. 緊急度を正しく設定 5. 1ケース=1質問 6. トラブルシュートは再現性が命 7. ログは重要な⼿がかり 8. 時刻はタイムゾーンを明確に 9. 解決理由を添えてクローズ 10. 不満がなければ満点評価 Effective AWS Support 10選

1.起票前にもう⼀度調べてみよう ● 同僚に相談 ● 公式ドキュメントを確認 ● 公式フォーラムre:Postを確認 ● Xのようなソーシャルメディアを確認 ● DevelopersIOのような技術ブログを確認 11

2. 2種類の窓⼝を使い分ける ● アカウントと請求 ○ 請求、料⾦、AWSアカウント ■ 例)S3の利⽤費の計算 ● 技術 ○ 技術⽀援 ■ 例)S3のバケットポリシー 12

3.解決の定義を明確に ● ケースの起票＝第三者にサポートを依頼 ● 困っていることに共感してもらうだけでは 不⼗分 ● どうなるとケースを解決したとみなせるの か、そのためにどういう⽀援が必要なのか 共通の認識を持てるようにする 13

4.緊急度を正しく設定 ● 緊急度(優先度)は明確に定義されている ● ⾼緊急度なケースは具体的な数字を含めた ビジネスインパクトを添える ● 例)1時間にX件の注⽂があり、Y万円の売上 のあるECサイトがアクセスできない状態 14

アカウント系の緊急度レベル ● ⼀般的な質問 ○ アカウントまたは請求に関する⼀般的な質問がある。 ● 重要な質問 ○ 時間的制約のあるアカウントまたは請求に関する質問があるが、それはビジネスの⽣産性に影響を与えてい ない。 ● ビジネスの障害に関する質問 ○ ビジネスの⽣産性の⼀部を損なっている時間的制約のあるアカウントまたは請求に関する質問がある。 ● ビジネスに影響のある緊急の質問 ○ お客様のビジネスがリスクにさらされる時間的制約のあるアカウントまたは請求に関する質問またはサービ スクォータの増加がある。 ● 重要なビジネスリスクの質問 ○ お客様のビジネスに⼤きな影響を与えている時間的制約のあるアカウントまたは請求に関する質問または サービスクォータの増加がある 15

技術系の緊急度レベル ● ⼀般的な質問、または機能要望 ○ ⼀般的な開発のご質問か、または機能追加のご要望がある。 ● 問題発⽣中、または開発中の急ぎの問い合わせ ○ アプリケーションにて致命的ではない機能の挙動に異常が⾒られるか、または急を要する開発の質問があ る。 ● 本番環境の重要な機能に障害発⽣中 ○ アプリケーションの極めて重要な機能が損なわれているか、または低下している。 ● 本番環境のシステム停⽌中 ○ ビジネスが深刻な影響を受けている。アプリケーションの重要な機能が利⽤できない。 ● 本番環境のビジネスクリティカルなシステム停⽌中 ○ ビジネスがリスクにさらされている。アプリケーションの極めて重要な機能が利⽤できない。 16

5.1ケース=1質問 ● ケースに複数の質問 ○ 回答作成に時間がかかる ○ 複数領域にまたがる包括的な対応は難易度があがる ○ すべての質問が解決するまでケースを解決できない ● 関連する質問はまとめてOK ○ 同⼀サービスの複数の仕様確認 ○ 発⽣中の障害に対して、障害復旧と原因調査をやりたい場 合、対応内容も時間軸も異なる。優先度をつける 17

6.トラブルシュートは再現性が命 ● 再現可能な障害は解決も容易 ● 問題の切り分けだけでも⼗分 ○ 原因の絞り込みに多いに役⽴つ 18

7.ログは重要な⼿がかり ● ログメッセージは情報の宝庫 ● テキスト情報を活⽤しやすいよう、画像 キャプチャではなく、テキスト形式で共有 ● 共有時に機密情報は除外 19

8.時刻はタイムゾーンを明確に ● AWSでは2種類の時刻がある ○ ローカルタイム(例:⽇本標準時/JST) ○ UTC(基準時刻) ● 障害発⽣、メトリクス、ログのタイムスタ ンプなど、どの時刻なのか明確に 20

9.解決理由を添えてクローズ ● 能動的にクローズ理由を添えてクローズし てナレッジ化 ○ サポートの提案がうまくいったのか、⾃ ⼰解決したのか? ● 時間の経過による⾃動クローズに任せない 21

10.不満がなければ満点評価 ● 回答やケースにフィードバックを提供 ● 評価は「⾮常に良い」からの減点⽅式 ● 品質向上につながるような具体的コメント 22 回答のフィードバック ケースのフィードバック

23 1. 起票前にもう⼀度調べてみよう 2. 2種類の窓⼝を使い分ける 3. 解決の定義を明確に 4. 緊急度を正しく設定 5. 1ケース=1質問 6. トラブルシュートは再現性が命 7. ログは重要な⼿がかり 8. 時刻はタイムゾーンを明確に 9. 解決理由を添えてクローズ 10. 不満がなければ満点評価 Effective AWS Support 10選

参考 24

AWSサポート 25 https://aws.amazon.com/jp/premiumsupport/

技術問い合わせのガイドライン 26 https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/

No content

No content