DevOps Bootcamp · บทเรียน

สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ

ออกแบบการดำเนินการให้เรียกซ้ำได้อย่างปลอดภัย และเพิ่มการถอยกลับแบบทวีคูณสำหรับการเรียกภายนอกที่ไม่เสถียร

สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ เป็นบทเรียน DevOps Bootcamp ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน DevOps Bootcamp และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน

Idempotency คืออะไรและเหตุใดจึงสำคัญ

Idempotency หมายถึงการเรียกใช้การดำเนินการเดิมหลายครั้งแล้วได้ผลลัพธ์เหมือนกับการเรียกใช้เพียงครั้งเดียว ในการเขียนสคริปต์ Bash แนวคิดนี้สำคัญมาก เพราะสคริปต์อาจหยุดทำงาน เครือข่ายอาจขัดข้อง และผู้ใช้อาจเรียกใช้ซ้ำโดยไม่ตั้งใจ

สคริปต์ที่ไม่เป็น idempotent และสร้างผู้ใช้ซ้ำอาจล้มเหลวหรือทำให้ข้อมูลซ้ำ
สคริปต์ที่เป็น idempotent จะตรวจสอบก่อนว่า มีสิ่งนี้อยู่แล้วหรือไม่
สคริปต์แบบ idempotent ปลอดภัยสำหรับใช้ในงาน cron กระบวนการส่งต่อของ CI และลูปการลองใหม่

กฎสำคัญคือ ตรวจสอบก่อนดำเนินการ การดำเนินการที่ทำลายข้อมูลหรือสร้างสิ่งใหม่ทุกอย่างควรมีการตรวจสอบเงื่อนไขก่อนดำเนินการกำกับไว้

การป้องกันการสร้างไฟล์และไดเรกทอรีซ้ำ

รูปแบบ idempotency ที่ใช้บ่อยที่สุดคือการตรวจสอบว่าทรัพยากรมีอยู่แล้วหรือไม่ก่อนสร้าง Bash มีคำสั่งบรรทัดเดียวที่กระชับสำหรับงานนี้

[ -d dir ] — เป็นจริงหากมีไดเรกทอรีอยู่
[ -f file ] — เป็นจริงหากมีไฟล์ปกติอยู่
mkdir -p — สร้างไดเรกทอรีเฉพาะเมื่อยังไม่มี (มี idempotency ในตัว)

ควรเลือกใช้แฟล็กที่มีมาให้ในตัว เช่น -p และ --no-clobber แทนการตรวจสอบด้วยตนเองเมื่อมีให้ใช้ — เนื่องจากแฟล็กเหล่านี้ทำงานแบบอะตอมิกและปลอดภัยจากสภาวะแข่งขัน

#!/usr/bin/env bash
set -euo pipefail

CONFIG_DIR="$HOME/.myapp"
CONFIG_FILE="$CONFIG_DIR/config.ini"

# Idempotent: mkdir -p never fails if dir already exists
mkdir -p "$CONFIG_DIR"

# Idempotent: only write config if it doesn't exist yet
if [ ! -f "$CONFIG_FILE" ]; then
  echo '[defaults]' > "$CONFIG_FILE"
  echo 'timeout=30' >> "$CONFIG_FILE"
  echo "Created $CONFIG_FILE"
else
  echo "Config already exists, skipping."
fi

การจัดการผู้ใช้และกลุ่มแบบ Idempotent

งานดูแลระบบ เช่น การเพิ่มผู้ใช้หรือกลุ่ม ต้องเป็นแบบ idempotent — การเรียกใช้สคริปต์ซ้ำบนเครื่องเดิมไม่ควรทำให้เกิดข้อผิดพลาดหรือสร้างรายการซ้ำ

id username คืนค่า 0 หากมีผู้ใช้อยู่
getent group groupname ตรวจสอบว่ามีกลุ่มอยู่หรือไม่
ครอบการดำเนินการแต่ละรายการด้วยเงื่อนไขป้องกัน เพื่อให้สคริปต์ปลอดภัยเมื่อนำกลับมาเรียกใช้ซ้ำ

รูปแบบนี้เป็นพื้นฐานของเครื่องมือจัดการการกำหนดค่า เช่น Ansible — งานทุกงานคือการดำเนินการแบบ idempotent ที่มีเงื่อนไขป้องกัน

#!/usr/bin/env bash
set -euo pipefail

APP_USER="apprunner"
APP_GROUP="appgroup"

# Idempotent group creation
if ! getent group "$APP_GROUP" &>/dev/null; then
  groupadd "$APP_GROUP"
  echo "Group '$APP_GROUP' created."
else
  echo "Group '$APP_GROUP' already exists."
fi

# Idempotent user creation
if ! id "$APP_USER" &>/dev/null; then
  useradd -m -g "$APP_GROUP" -s /bin/bash "$APP_USER"
  echo "User '$APP_USER' created."
else
  echo "User '$APP_USER' already exists."
fi

การใช้ไฟล์ล็อกเพื่อป้องกันการทำงานพร้อมกัน

แม้แต่สคริปต์แบบ idempotent ก็อาจก่อปัญหาได้หากมีอินสแตนซ์สองชุดทำงานพร้อมกัน ไฟล์ล็อกช่วยให้มีอินสแตนซ์ทำงานได้ครั้งละหนึ่งชุดเท่านั้น

สร้างไฟล์ล็อกเมื่อเริ่มทำงาน และลบไฟล์เมื่อสิ้นสุด
ใช้ trap เพื่อล้างไฟล์ล็อกแม้สคริปต์จะถูกขัดจังหวะ
การใช้ mkdir กับเส้นทางเดียวเป็นการทำงานแบบอะตอมิกบนระบบไฟล์ Linux ส่วนใหญ่ จึงปลอดภัยกว่าการใช้ touch เพื่อล็อก

หากไม่มีล็อก งาน cron ที่ทำงานช้าและการเรียกใช้ซ้ำด้วยตนเองอาจชนกันและทำให้สถานะที่ใช้ร่วมกันเสียหาย

#!/usr/bin/env bash
set -euo pipefail

LOCKFILE="/tmp/myapp_deploy.lock"

# Atomic lock acquisition using mkdir
if ! mkdir "$LOCKFILE" 2>/dev/null; then
  echo "ERROR: Another instance is running (lock: $LOCKFILE). Exiting." >&2
  exit 1
fi

# Guarantee lock removal on any exit
trap 'rmdir "$LOCKFILE"; echo "Lock released."' EXIT

echo "Lock acquired. Running deployment..."
sleep 2   # simulate work
echo "Deployment complete."

การติดตามขั้นตอนที่เสร็จสิ้นด้วยไฟล์สถานะ

สำหรับสคริปต์ที่มีหลายขั้นตอน (การย้ายข้อมูล การติดตั้ง การจัดเตรียมระบบ) คุณสามารถติดตามว่าขั้นตอนไหนเสร็จสิ้นแล้วด้วย ไฟล์สถานะ แต่ละขั้นตอนจะตรวจสอบไฟล์สถานะก่อนดำเนินการ และเขียนลงไฟล์เมื่อเสร็จสิ้น

ประหยัดและใช้ได้หลากหลาย — ไม่ต้องใช้ฐานข้อมูล
ช่วยให้สคริปต์ที่ล้มเหลวทำงานต่อจากจุดที่หยุดไว้ได้
เก็บสถานะไว้ในตำแหน่งที่คาดเดาได้ เช่น /var/lib/myapp/ หรือ ~/.myapp/state/

รูปแบบนี้ใช้โดยเครื่องมือสำคัญอย่าง apt, cloud-init และโครงสร้างการย้ายข้อมูลฐานข้อมูล

#!/usr/bin/env bash
set -euo pipefail

STATE_DIR="/tmp/myapp_state"
mkdir -p "$STATE_DIR"

run_step() {
  local step_name="$1"
  local step_cmd="$2"
  local marker="$STATE_DIR/${step_name}.done"

  if [ -f "$marker" ]; then
    echo "[SKIP] $step_name already completed."
    return 0
  fi

  echo "[RUN]  $step_name ..."
  eval "$step_cmd"
  touch "$marker"
  echo "[DONE] $step_name"
}

run_step "install_deps"   "echo 'Installing dependencies...'"
run_step "configure_db"   "echo 'Configuring database...'"
run_step "start_service"  "echo 'Starting service...'"

บทนำเกี่ยวกับตรรกะการลองใหม่

การเรียกใช้ภายนอก — คำขอ HTTP การค้นหา DNS และการเรียกใช้ API ของคลาวด์ — ล้วนไม่น่าเชื่อถือโดยธรรมชาติ ความล้มเหลวเพียงครั้งเดียวไม่ควรยุติสคริปต์ทั้งหมดของคุณ ตรรกะการลองใหม่จะเรียกใช้คำสั่งที่ล้มเหลวซ้ำโดยอัตโนมัติ

การลองใหม่แบบง่าย: วนซ้ำ N ครั้งจนกว่าคำสั่งจะสำเร็จ
กำหนดจำนวนครั้งสูงสุดของการลองใหม่เสมอ เพื่อป้องกันลูปไม่รู้จบ
บันทึกความพยายามแต่ละครั้งเพื่อให้วินิจฉัยความล้มเหลวได้

ฟังก์ชันการลองใหม่ที่ง่ายที่สุดจะครอบคำสั่งใด ๆ และลองใหม่ไม่เกินจำนวนครั้งที่กำหนด โดยหน่วงเวลาด้วยค่าคงที่ วิธีนี้เพียงพอสำหรับกรณีใช้งานจำนวนมาก แต่มีข้อบกพร่องสำคัญเมื่อมีโหลดสูง ซึ่งจะกล่าวถึงในหัวข้อถัดไป

#!/usr/bin/env bash
set -euo pipefail

# Simple fixed-delay retry (3 attempts, 2s apart)
retry() {
  local max_attempts=3
  local delay=2
  local attempt=1

  until "$@"; do
    if (( attempt >= max_attempts )); then
      echo "ERROR: Command failed after $max_attempts attempts: $*" >&2
      return 1
    fi
    echo "Attempt $attempt failed. Retrying in ${delay}s..." >&2
    sleep "$delay"
    (( attempt++ ))
  done
}

# Example: retry a curl call
retry curl --silent --fail --max-time 5 https://httpbin.org/get -o /dev/null
echo "Request succeeded."

ปัญหาฝูงชนแห่กันลองใหม่

เมื่อไคลเอ็นต์จำนวนมากลองใหม่พร้อมกันหลังเกิดความล้มเหลว จะเกิด ฝูงชนแห่กันลองใหม่ — ทุกไคลเอ็นต์ลองใหม่ในช่วงเวลาคงที่เดียวกัน ส่งคำขอไปยังเซิร์ฟเวอร์พร้อมกันพอดีและทำให้ไม่สามารถกู้คืนระบบได้

สคริปต์ 100 ชุดลองใหม่ทุก 5 วินาที → มีคำขอพร้อมกัน 100 รายการทุก 5 วินาที
เซิร์ฟเวอร์กำลังรับภาระหนักอยู่แล้ว โหลดที่เกิดพร้อมกันยิ่งทำให้สถานการณ์แย่ลง
วิธีแก้คือ การหน่วงเวลาแบบทวีคูณ: เพิ่มเวลารอเป็นสองเท่าหลังเกิดความล้มเหลวแต่ละครั้ง
เพิ่ม ความแปรปรวนแบบสุ่ม เพื่อทำให้การลองใหม่ของไคลเอ็นต์แต่ละตัวไม่ตรงกัน

การหน่วงเวลาแบบทวีคูณร่วมกับความแปรปรวนแบบสุ่มเป็นมาตรฐานของอุตสาหกรรม ซึ่งใช้โดย AWS SDK, ไคลเอ็นต์ Google Cloud และระบบแบบกระจายขนาดใหญ่ทุกระบบ

การใช้งานการหน่วงเวลาแบบทวีคูณ

การหน่วงเวลาแบบทวีคูณจะเพิ่มเวลารอเป็นลำดับทวีคูณหลังการล้มเหลวแต่ละครั้ง: 1 วินาที, 2 วินาที, 4 วินาที, 8 วินาที, 16 วินาที... วิธีนี้ช่วยให้ระบบปลายทางมีเวลาฟื้นตัว พร้อมลดภาระงานโดยรวม

สูตรคือ: delay = base * (2 ^ attempt)

กำหนดขีดจำกัด (เวลาหน่วงสูงสุด) เพื่อไม่ให้เวลารอเพิ่มขึ้นโดยไม่มีขอบเขต
พารามิเตอร์ที่ควรปรับ: base_delay, max_delay, max_attempts

ฟังก์ชันนี้นำกลับมาใช้ซ้ำได้ โดยส่งคำสั่งใด ๆ ให้ฟังก์ชันเป็นอาร์กิวเมนต์

#!/usr/bin/env bash
set -euo pipefail

retry_with_backoff() {
  local max_attempts="${RETRY_MAX_ATTEMPTS:-5}"
  local base_delay="${RETRY_BASE_DELAY:-1}"
  local max_delay="${RETRY_MAX_DELAY:-30}"
  local attempt=0
  local delay="$base_delay"

  until "$@"; do
    (( attempt++ ))
    if (( attempt >= max_attempts )); then
      echo "ERROR: '$*' failed after $max_attempts attempts." >&2
      return 1
    fi
    echo "Attempt $attempt failed. Backing off for ${delay}s..." >&2
    sleep "$delay"
    # Double the delay, but cap it
    delay=$(( delay * 2 ))
    (( delay > max_delay )) && delay=$max_delay
  done

  echo "Command succeeded on attempt $(( attempt + 1 ))."
}

retry_with_backoff echo "Simulated success"

การเพิ่มการสุ่มให้กับการหน่วงเวลา

การสุ่มคลาดเคลื่อนจะเพิ่มความสุ่มให้กับเวลาหน่วงเพื่อการลองใหม่ แม้ใช้การหน่วงเวลาแบบทวีคูณ หากไคลเอนต์ทั้งหมดเริ่มทำงานพร้อมกัน ก็ยังคงลองใหม่พร้อมกันเป็นจังหวะเดียวกัน การสุ่มคลาดเคลื่อนจะช่วยทำลายการประสานจังหวะนี้

กลยุทธ์การสุ่มที่ใช้กันทั่วไปมีสองแบบ:

การสุ่มเต็มช่วง: sleep random(0, cap) — กระจายตัวได้มากที่สุดและมีภาระงานสูงสุดต่ำที่สุด
การสุ่มครึ่งช่วง: sleep cap/2 + random(0, cap/2) — รับประกันเวลารอขั้นต่ำและหลีกเลี่ยงการส่งคำขอถี่ ๆ ทันที

ใน Bash ให้ใช้ $RANDOM (0–32767) เพื่อสร้างตัวเลขสุ่ม แล้วปรับให้อยู่ในช่วงเวลาหน่วงด้วยการคำนวณหาเศษเหลือ

#!/usr/bin/env bash
set -euo pipefail

retry_with_jitter() {
  local max_attempts="${1:-5}"; shift
  local base_delay=1
  local max_delay=32
  local attempt=0
  local cap=$base_delay

  until "$@"; do
    (( attempt++ ))
    if (( attempt >= max_attempts )); then
      echo "ERROR: Giving up after $max_attempts attempts." >&2
      return 1
    fi

    # Full jitter: random value in [0, cap]
    local jitter=$(( RANDOM % (cap + 1) ))
    echo "Attempt $attempt failed. Sleeping ${jitter}s (cap=${cap}s)..." >&2
    sleep "$jitter"

    # Grow cap exponentially, bounded by max_delay
    cap=$(( cap * 2 ))
    (( cap > max_delay )) && cap=$max_delay
  done
}

retry_with_jitter 4 curl --silent --fail --max-time 3 https://httpbin.org/get -o /dev/null
echo "Done."

การผสานความเป็นไอดีมโพเทนต์กับการลองใหม่ในกระบวนการทำงานจริง

ในสคริปต์สำหรับใช้งานจริง ตรรกะความเป็นไอดีมโพเทนต์และการลองใหม่จะทำงานร่วมกัน กระบวนการนำส่งทั่วไปอาจทำดังนี้:

ขอล็อก (ป้องกันการทำงานพร้อมกัน)
ตรวจสอบไฟล์สถานะ (ข้ามขั้นตอนที่เสร็จแล้ว)
ใช้การลองใหม่พร้อมหน่วงเวลาเพิ่มสำหรับการเรียกภายนอก (ดาวน์โหลด, API, DNS)
ทำเครื่องหมายว่าขั้นตอนเสร็จแล้วเฉพาะหลังยืนยันความสำเร็จ
ปลดล็อกผ่าน trap

การผสานแนวทางนี้ทำให้สคริปต์ปลอดภัยต่อการเรียกใช้ซ้ำได้ทุกจุด ไม่ว่าจะหลังโปรแกรมขัดข้อง เวลาหมด หรือยกเลิกด้วยตนเอง โดยไม่ทำให้ระบบอยู่ในสถานะเสียหาย

#!/usr/bin/env bash
set -euo pipefail

STATE_DIR="/tmp/deploy_state" && mkdir -p "$STATE_DIR"
LOCK="/tmp/deploy.lock"

mkdir "$LOCK" 2>/dev/null || { echo "Already running."; exit 1; }
trap 'rmdir "$LOCK"' EXIT

step_done() { [ -f "$STATE_DIR/$1.done" ]; }
mark_done() { touch "$STATE_DIR/$1.done"; }

retry_backoff() {
  local attempt=0 delay=1
  until "${@:2}"; do
    (( ++attempt >= $1 )) && { echo "Failed after $1 attempts."; return 1; }
    echo "Retry $attempt in ${delay}s..."; sleep $delay; delay=$(( delay * 2 ))
  done
}

if ! step_done "download_artifact"; then
  retry_backoff 4 curl -fsSL https://httpbin.org/get -o /tmp/artifact.json
  mark_done "download_artifact"
  echo "[DONE] download_artifact"
else
  echo "[SKIP] download_artifact"
fi

echo "Deployment finished successfully."

การจัดการข้อผิดพลาดที่ไม่ควรลองใหม่

ข้อผิดพลาดทุกประเภทไม่ควรนำมาลองใหม่ การลองใหม่เมื่อได้รับ 404 Not Found หรือ 403 Forbidden เป็นการสิ้นเปลือง เพราะจะไม่มีวันสำเร็จหากไม่มีการดำเนินการจากมนุษย์ ตรรกะการลองใหม่ควรแยกแยะระหว่าง:

ข้อผิดพลาดชั่วคราว — เวลารอเครือข่ายหมด, 503 Service Unavailable, DNS ล้มเหลว → ลองใหม่
ข้อผิดพลาดถาวร — 401 Unauthorized, 404 Not Found, ข้อมูลนำเข้าไม่ถูกต้อง → ล้มเหลวทันที

เมื่อใช้ curl ให้ตรวจสอบรหัสสถานะ HTTP และข้ามการลองใหม่สำหรับการตอบกลับกลุ่ม 4xx ใช้ --write-out '%{http_code}' เพื่อเก็บสถานะแยกจากเนื้อหาการตอบกลับ

#!/usr/bin/env bash
set -euo pipefail

fetch_with_retry() {
  local url="$1"
  local max_attempts=4
  local delay=1
  local attempt=0
  local http_code

  until http_code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$url"); do
    : # curl itself failed (network error)
    (( ++attempt >= max_attempts )) && { echo "Network error, giving up."; return 1; }
    sleep $delay; delay=$(( delay * 2 ))
  done

  # Permanent client errors — do not retry
  if [[ "$http_code" =~ ^4 ]]; then
    echo "ERROR: HTTP $http_code for $url — not retrying." >&2
    return 1
  fi

  # Transient server errors — retry
  if [[ "$http_code" =~ ^5 ]]; then
    (( ++attempt >= max_attempts )) && { echo "Server error, giving up."; return 1; }
    echo "HTTP $http_code — backing off ${delay}s..."
    sleep $delay; delay=$(( delay * 2 ))
    fetch_with_retry "$url"
    return
  fi

  echo "HTTP $http_code — success."
}

fetch_with_retry "https://httpbin.org/status/200"

ตรวจสอบความรู้: การเลือกกลยุทธ์การหน่วงเวลา

สคริปต์นำส่งดาวน์โหลดไฟล์ผลลัพธ์ของรุ่นจากบักเก็ต S3 ในเหตุขัดข้องครั้งล่าสุด อินสแตนซ์ของกระบวนการทั้งหมด 80 รายการล้มเหลวพร้อมกันเนื่องจาก S3 หยุดให้บริการชั่วครู่ เมื่อ S3 กลับมาใช้งานได้หลังจาก 10 วินาที อินสแตนซ์ทั้ง 80 รายการก็ลองใหม่พร้อมกันในเวลาเดียวกัน ทำให้เกิดภาระงานเกินอีกครั้งและทำให้ช่วงขัดข้องยาวนานขึ้น 3 นาที

กลยุทธ์การลองใหม่แบบใดจะช่วยป้องกันเหตุการณ์ถาโถมแบบฝูงชนนี้ได้ดีที่สุดในการขัดข้องครั้งต่อไป

ทบทวน: ความเป็นไอดีมโพเทนต์และการลองใหม่พร้อมหน่วงเวลาเพิ่ม

ในบทเรียนนี้ คุณได้เรียนรู้วิธีออกแบบสคริปต์ Bash ที่ปลอดภัยต่อการเรียกใช้ซ้ำและรับมือกับความล้มเหลวชั่วคราวได้ดี

รูปแบบความเป็นไอดีมโพเทนต์:

ตรวจสอบการมีอยู่ก่อนทุกการดำเนินการ ([ -f ], [ -d ], id, getent)
ใช้ mkdir -p และตัวเลือกในตัวอื่น ๆ ที่ทำให้การทำงานเป็นไอดีมโพเทนต์เมื่อมีให้ใช้
ใช้ไฟล์ล็อก (mkdir แบบอะตอมิก) เพื่อป้องกันการทำงานพร้อมกัน
ใช้ไฟล์สถานะ (ไฟล์เครื่องหมายสำหรับแต่ละขั้นตอน) เพื่อให้ทำงานต่อหลังเกิดความล้มเหลวได้

รูปแบบการลองใหม่พร้อมหน่วงเวลาเพิ่ม:

กำหนดจำนวนครั้งสูงสุดที่ลองเสมอ — อย่าลองใหม่ไม่สิ้นสุด
ใช้การหน่วงเวลาแบบทวีคูณ: เพิ่มเวลาหน่วงเป็นสองเท่าหลังความล้มเหลวแต่ละครั้ง
เพิ่มการสุ่มคลาดเคลื่อนเพื่อป้องกันการลองพร้อมกันแบบฝูงชน
แยกแยะข้อผิดพลาดชั่วคราว (ลองใหม่) จากข้อผิดพลาดถาวร (ล้มเหลวทันที)

การผสานรูปแบบเหล่านี้ทำให้ได้สคริปต์ระดับใช้งานจริง: ปลอดภัย ตรวจสอบติดตามได้ และซ่อมแซมตัวเองได้

คำถามที่พบบ่อย

บทเรียน “สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส DevOps Bootcamp ให้อัปเกรดเป็น CoddyKit PRO คอร์ส DevOps Bootcamp มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ”

ออกแบบการดำเนินการให้เรียกซ้ำได้อย่างปลอดภัย และเพิ่มการถอยกลับแบบทวีคูณสำหรับการเรียกภายนอกที่ไม่เสถียร คุณปฏิบัติ DevOps Bootcamp ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน DevOps Bootcamp หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน DevOps Bootcamp บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน DevOps Bootcamp นี้ได้ไหม

ได้ บทเรียน DevOps Bootcamp ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

โหมดเข้มงวดด้วย set -euo pipefail
ตัวจัดการ trap สำหรับการล้างข้อมูลและสัญญาณ
ไฟล์ชั่วคราวและไดเรกทอรีล็อกที่ปลอดภัย
สคริปต์แบบทำซ้ำได้อย่างปลอดภัยและตรรกะลองใหม่แบบถอยกลับ

← กลับไปที่ DevOps Bootcamp