מעבדה מעשית — SOA-C03 AWS Certified CloudOps Engineer Associate

סקירה כללית

דרישות קדם

שלבים

1. 1.בחר את גרסת Terraform ואזור AWS שלנו

   פתיחה סטנדרטית. default_tags חלים על כל המחסנית כך שצוות התפעול יוכל לסנן מאוחר יותר את Cost Explorer, AWS Config ו-Tag Editor לפי Project = certlabpro-soa-c03 כדי לראות את כל מה שהמעבדה יצרה. תחום אמינות והמשכיות עסקית של SOA-C03 בודק זאת במפורש — תיוג הוא הבסיס לכל שאילתה תפעולית רוחבית.

   העתק

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.60"
       }
     }
   }
   
   provider "aws" {
     region = "us-east-1"
   
     default_tags {
       tags = {
         Project   = "certlabpro-soa-c03"
         ManagedBy = "terraform"
       }
     }
   }

2. 2.הגדר קבוצת יומנים עם שמירה ומסנן מדדים עבור הדבר שאכפת לנו ממנו

   משאבים:

   • Amazon CloudWatch Logs

   כל סיפור תפעולי ב-AWS מתחיל ב-CloudWatch Logs. אנו יוצרים קבוצת יומנים עם שמירה מפורשת של 30 יום (ברירת המחדל של לעולם אל תפוג היא האנטי-תבנית של עלות SOA-C03 שעולה בכל שאלה על אופטימיזציית עלויות) ו-מסנן מדדים שעוקב אחר זרם היומנים למילה ERROR ומפרסם ספירה ל-CloudWatch Metrics.

   מסנני מדדים הופכים נתוני יומן לא מובנים למדדים ניתנים לפעולה. זהו המודל המנטלי של SOA-C03 לניטור: יומנים ← מסנן ← מדד ← התראה ← SNS ← אדם (או אוטומציה). אנו בונים את השרשרת חלק אחר חלק החל משלב זה.

   העתק

   resource "aws_cloudwatch_log_group" "app" {
     name              = "/certlabpro/soa-c03/app"
     retention_in_days = 30
   }
   
   resource "aws_cloudwatch_log_metric_filter" "app_errors" {
     name           = "certlabpro-soa-c03-app-errors"
     log_group_name = aws_cloudwatch_log_group.app.name
     pattern        = "ERROR"
   
     metric_transformation {
       name          = "AppErrorCount"
       namespace     = "CertLabPro/SOA-C03"
       value         = "1"
       default_value = "0"
     }
   }

3. 3.התראה על המדד וניתוב התראות דרך SNS לבן אדם

   משאבים:

   • Amazon CloudWatch
   • Amazon SNS

   כעת אנו מחברים את המדד משלב 2 לבן אדם. אנו יוצרים נושא SNS, מנויים אליו כתובת דוא"ל, ומגדירים התראת CloudWatch שמופעלת כאשר ספירת השגיאות עוברת את הסף שלנו. SOA-C03 בודק את השרשרת המדויקת הזו — מדד ← התראה ← SNS ← דוא"ל — תחת תחום ניטור, רישום ותיקון (~20% מהבחינה).

   לאחר terraform apply, AWS שולחת דוא"ל אישור לכתובת ב-endpoint — לחץ/י על Confirm subscription פעם אחת, וההתראה תגיע אליך בפועל כאשר היא תופעל.

   treat_missing_data = "notBreaching" הוא פרט קטן אך רלוונטי לבחינה: כברירת מחדל, נקודת נתונים חסרה נחשבת כהפרה, מה שאומר שהתראה חדשה לגמרי ללא נתונים מופעלת מיד. הגדרתה ל-notBreaching תואמת את מוסכמת SOA-C03 עבור מדדים בנפח נמוך.

   העתק

   resource "aws_sns_topic" "ops_alerts" {
     name = "certlabpro-soa-c03-ops-alerts"
   }
   
   resource "aws_sns_topic_subscription" "ops_email" {
     topic_arn = aws_sns_topic.ops_alerts.arn
     protocol  = "email"
     endpoint  = "ops@example.com" # replace with your real email
   }
   
   resource "aws_cloudwatch_metric_alarm" "app_errors_spike" {
     alarm_name          = "certlabpro-soa-c03-app-errors-spike"
     comparison_operator = "GreaterThanThreshold"
     evaluation_periods  = 1
     metric_name         = "AppErrorCount"
     namespace           = "CertLabPro/SOA-C03"
     period              = 300
     statistic           = "Sum"
     threshold           = 10
     alarm_description   = "More than 10 ERROR log lines in 5 minutes."
     alarm_actions       = [aws_sns_topic.ops_alerts.arn]
     treat_missing_data  = "notBreaching"
   }

4. 4.כתוב ספר הפעלה של Systems Manager לתיקון האוטומטי

   משאבים:

   • AWS Systems Manager

   התראת אדם היא בסדר עבור אירועים חדשים אך יקרה עבור אירועים חוזרים ידועים. SOA-C03 נשען בכבדות על AWS Systems Manager Automation כתשובה לשאלה "איך אוכל לתקן אוטומטית את הדברים שאני כבר יודע לתקן?" — הפעלה מחדש של שירות לא תקין, סיבוב אישורי גישה, ניקוי שטח דיסק.

   אנו יוצרים מסמך SSM מינימלי המריץ שלב aws:sleep (אחד מסוגי השלבים המנוהלים על ידי AWS) — בייצור זה יהיה aws:executeAutomation מול ספר הפעלה ידוע לשחזור, או aws:runCommand מול צי מופעים. הצורה זהה: הכרז על רצף שלבים, תן למסמך תפקיד ביצוע, רשום אותו כאוטומציה הניתנת לשימוש חוזר.

   תפקיד ה-IAM שאנו מצרפים מעניק ל-SSM Automation הרשאה לקבל על עצמו את התפקיד ולקרוא לפעולות בתוך המסמך. תחום אמינות והמשכיות עסקית של SOA-C03 בודק תבנית מדויקת זו: ספר הפעלה בעל שם ובקרת גרסאות ניתן לביקורת; הודעת סלאק האומרת "היי, אתה יכול להפעיל מחדש את הדבר הזה" אינה ניתנת.

   העתק

   resource "aws_iam_role" "ssm_automation" {
     name = "certlabpro-soa-c03-ssm-automation"
   
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect    = "Allow"
         Principal = { Service = "ssm.amazonaws.com" }
         Action    = "sts:AssumeRole"
       }]
     })
   }
   
   resource "aws_iam_role_policy_attachment" "ssm_automation" {
     role       = aws_iam_role.ssm_automation.name
     policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole"
   }
   
   resource "aws_ssm_document" "remediate_app_errors" {
     name            = "certlabpro-soa-c03-remediate-app-errors"
     document_type   = "Automation"
     document_format = "YAML"
   
     content = <<-EOT
       schemaVersion: "0.3"
       description: "Lab-only runbook — auto-acknowledges app-error spikes."
       assumeRole: "${aws_iam_role.ssm_automation.arn}"
       mainSteps:
         - name: pause
           action: aws:sleep
           inputs:
             Duration: PT5S
     EOT
   }

5. 5.חבר את EventBridge כך שאירועי התראה בדרגת חומרה גבוהה יפעילו את ספר ההפעלה

   משאבים:

   • Amazon EventBridge
   • AWS IAM

   החלק האחרון בלולאה. התראות CloudWatch פולטות אירועים לאפיק ברירת המחדל של EventBridge כאשר הן משנות מצב — אנו מסננים את ההתראה שיצרנו בשלב 3 העוברת למצב ALARM, ומטרגטים את מסמך SSM משלב 4 כתגובה.

   כלל EventBridge זקוק לתפקיד IAM משלו כדי לקרוא ל-SSM Automation בשמנו — זהו פרט עדין אך חוזר ב-SOA-C03. הבחינה בודקת אם אתה זוכר/ת ש-הפעלת יעד על ידי EventBridge בשמך היא פעולה שירות-לשירות הדורשת תפקיד ביצוע ייעודי, נפרד מתפקיד ההנחה של מסמך ה-SSM עצמו.

   השרשרת המלאה כעת היא: שורת יומן המכילה ERROR ← מסנן מדדים מפרסם ל-CloudWatch Metrics ← התראה מופעלת כאשר הספירה > 10 ב-5 דקות ← התראה מפרסמת אירוע שינוי מצב ל-EventBridge וגם שולחת דוא"ל לצוות התפעול באמצעות SNS ← כלל EventBridge תואם את שינוי המצב ← SSM Automation מריץ את ספר הפעלה לתיקון. הביפר מופעל והתיקון מתחיל במקביל. זהו האידיאל התפעולי של SOA-C03.

   העתק

   resource "aws_iam_role" "eventbridge_invoke_ssm" {
     name = "certlabpro-soa-c03-eventbridge-invoke-ssm"
   
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect    = "Allow"
         Principal = { Service = "events.amazonaws.com" }
         Action    = "sts:AssumeRole"
       }]
     })
   }
   
   resource "aws_iam_role_policy" "eventbridge_invoke_ssm" {
     name = "start-automation"
     role = aws_iam_role.eventbridge_invoke_ssm.id
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect = "Allow"
         Action = "ssm:StartAutomationExecution"
         Resource = "*"
       }]
     })
   }
   
   resource "aws_cloudwatch_event_rule" "app_errors_alarm" {
     name        = "certlabpro-soa-c03-app-errors-alarm-fired"
     description = "Fires the auto-remediation runbook when the app-errors alarm trips."
   
     event_pattern = jsonencode({
       source      = ["aws.cloudwatch"]
       "detail-type" = ["CloudWatch Alarm State Change"]
       detail = {
         alarmName = [aws_cloudwatch_metric_alarm.app_errors_spike.alarm_name]
         state     = { value = ["ALARM"] }
       }
     })
   }
   
   resource "aws_cloudwatch_event_target" "run_ssm_doc" {
     rule     = aws_cloudwatch_event_rule.app_errors_alarm.name
     arn      = "arn:aws:ssm:us-east-1::automation-definition/${aws_ssm_document.remediate_app_errors.name}"
     role_arn = aws_iam_role.eventbridge_invoke_ssm.arn
   }

ניקוי משאבים