終於來到 Day 30。
這 30 天一開始，我想做的事情其實很單純：
把系統工程師每天重複做的事情，用 PowerShell 自動化。

最開始我們處理的事情並不複雜。
像是：
Get-Service
Get-Process
Get-ADUser

但一路做到 Day 29，整個專案已經從：
一條 PowerShell Command

慢慢長成：
PowerShell
↓
Function
↓
Configuration
↓
Remoting
↓
Windows Server Automation
↓
Active Directory Automation
↓
Error Handling
↓
Logging
↓
Scheduling
↓
Reporting
↓
Notification
↓
State Tracking
↓
Module
↓
Testing
↓
Git
↓
CI
↓
Release
↓
Deployment
↓
End-to-End Pipeline

所以 Day 30 不再新增新的技術。
今天要做的是：
把前 29 天全部串回來
看看我們到底做了什麼，以及這 30 天真正學到的東西，到底只是：
「會寫一些 PowerShell 指令」

還是已經開始變成：
「可以設計一套能被維護的 IT Automation Workflow。」

這 30 天我們到底在解決什麼問題？
系統工程師每天都會遇到很多重複工作。
例如：
查 AD 帳號
查閒置帳號
盤點 Computer Object
檢查 Server CPU
檢查 Memory
檢查 Disk
查看 Service
查 Event Log
整理 CSV
產生 Report
對很多 Server 執行一樣的 Command

如果環境只有：
3 台 Server
10 個 User

人工處理可能還可以。
但如果變成：
50 台 Server
100 台 Server
1000 個 AD User
幾千台 Computer Object

人工方式開始出現三個問題：
慢
容易漏
結果不一致

所以 Automation 的第一個目的不是：
為了看起來很厲害。

而是：
把大量、重複、可以明確定義規則的工作交給電腦。

Day 1～4｜先從 PowerShell 基礎開始
Day 1｜系統工程師為什麼需要自動化？
Day 1 我們沒有一開始就談：
Kubernetes
Terraform
Ansible
CI/CD

而是先看：
我每天到底有哪些事情在重複？

例如：
昨天查 Disk
今天再查一次

昨天查 AD
今天再查一次

SERVER01 跑一次
SERVER02 又跑一次
SERVER03 再跑一次

Automation 就是從：
我是不是又在做同一件事情？

開始。
Day 2｜PowerShell 基本 Cmdlet
我們開始熟悉：
Get-Command
Get-Help
Get-Member
Get-Service
Get-Process

以及 PowerShell 很重要的：
Verb-Noun

例如：
Get-Service
Stop-Service
Start-Service
Restart-Service

PowerShell 的命名方式讓 Command 相對容易猜。
Day 3｜Pipeline 與 Object
這是整個系列非常重要的一天。
PowerShell 不只是：
文字 → 文字

而是：
Object
↓
Object
↓
Object

例如：
Get-Service |
Where-Object Status -eq "Stopped" |
Select-Object Name, Status

真正傳遞的是：
Service Object

不是畫面上看到的純文字。
這也是後面為什麼可以：
Filter
Sort
Select
Export
ConvertTo-Html

做得這麼自然。
Day 4｜CSV 報表
我們第一次把：
查詢結果

變成：
可以保存的報表

例如：
$Results |
Export-Csv -Path ".\ServerReport.csv"
-NoTypeInformation `
-Encoding UTF8

從這一天開始，PowerShell 不只是：
畫面上看完就消失。

而開始留下：
Evidence
History
Report

Day 5～6｜開始真正做 Automation
Day 5｜變數、Array 與 foreach
以前：
Test-Connection SERVER01

接著：
Test-Connection SERVER02

再：
Test-Connection SERVER03

到了 Day 5：
$Servers = @(
"SERVER01"
"SERVER02"
"SERVER03"
)

foreach ($Server in $Servers) {

# Check

}

這就是：
單一操作
↓
批次操作

第一次真正開始有 Automation 的感覺。
Day 6｜Error Handling
但批次執行之後馬上會遇到：
SERVER01 成功
SERVER02 失敗
SERVER03 怎麼辦？

所以我們學：
try {
}
catch {
}
finally {
}

以及：
-ErrorAction Stop

從這一天開始，我一直強調：
Script 跑到最後，不代表所有工作都成功。

這個概念後面一路延伸到：
Success
Partial
Failed

甚至成為 Day 29 Pipeline 的核心。
Day 7～10｜正式進入 Windows Server 巡檢
Day 7｜CPU、Memory、Disk
開始使用：
Get-CimInstance

抓：
Win32_Processor
Win32_OperatingSystem
Win32_LogicalDisk

我們第一次建立：
CPU
Memory
Disk

的 Server Health Check。
而且開始加入：
Threshold

例如：
Normal
Warning
Critical

Day 8｜Service 與 Uptime
Server 健康度不能只看：
CPU
Memory

還需要：
Service
Uptime
LastBootTime

但這一天也開始建立一個很重要的觀念：
一個狀態本身不一定代表異常。

例如：
Stopped Service

如果它原本就不是應該自動執行的 Service，
就不代表：
Server 壞了。

Automation 的判斷必須有 Context。
Day 9｜Event Log
我們開始：
Get-WinEvent

查：
System
Application
Error
Warning
Event ID
Provider
Message

也學到：
Event Log 是 Evidence，不一定直接等於 Root Cause。

看到 Error：
代表值得調查

但不能直接說：
這就是根因。

Day 10｜PowerShell Remoting
前面我們還主要在：
本機

Day 10 開始進：
管理機
↓
SERVER01
SERVER02
SERVER03

使用：
Invoke-Command
Test-WSMan

並開始理解：
DNS
Network
WinRM
Firewall
Authentication
Permission

只要任何一層出問題，
Remote Automation 都可能失敗。
到這裡，我們已經從：
Single Server Script

變成：
Multi-Server Automation

Day 11～12｜讓 Script 變成可維護的工具
Day 11｜Function
如果所有東西一直寫在：
Main Script

最後很容易：
500 行
1000 行
1500 行

所以開始拆：
Get-CPUHealth
Get-MemoryHealth
Get-DiskHealth
Get-ServiceHealth
Get-ServerHealth
Write-Log

這是第一次正式開始：
Reuse
Day 12｜Configuration 與 Logic 分離
以前：
$Servers = @(
"SERVER01"
"SERVER02"
)

直接寫死在 Script。
Day 12 變：
ComputerName,Role,Environment,CPUWarning,CPUCritical
APP01,Application,Production,80,90
DB01,Database,Production,75,90

也就是：
Script
→ Logic

CSV
→ Configuration

這個概念後面非常重要。
因為同一套 Logic 可以套：
Production
Test
Application Server
Database Server

而不需要 Copy 四份 Script。
Day 13～19｜Active Directory Automation
這是整個系列第二個大區塊。
Day 13｜AD User、Computer、OU
我們正式使用：
Import-Module ActiveDirectory

Get-ADUser
Get-ADComputer
Get-ADOrganizationalUnit

以及：
-SearchBase
-SearchScope
-Properties

最重要的原則是：
先 Query，再 Action。

不要一開始學 AD PowerShell 就：
Remove-ADUser
Disable-ADAccount

先把查詢與範圍搞清楚。
Day 14｜Inactive User
我們開始找：
長期沒登入
從未登入

的 AD User。
也理解：
lastLogon
lastLogonTimestamp
LastLogonDate

不是完全相同的東西。
特別是：
LastLogonDate

很適合：
長期閒置帳號盤點。

但不適合：
分秒精準的即時登入判斷。

這一天也建立很重要的安全觀念
找到：
180 天未登入

不代表：
直接 Disable

因為可能是：
Service Account
Shared Account
Break Glass
Admin Account
Special System Account

所以流程應該：
Audit
↓
Report
↓
Review
↓
Approval
↓
Action

Day 15｜Inactive Computer
Computer Object 也一樣。
我們開始理解：
AD Computer Object ≠ Physical Asset。

一台 Computer Object 很久沒有活動：
值得調查

但不能直接認定：
這台實體電腦已經不存在。

可能還要 Cross-check：
Asset Inventory
DNS
DHCP
EDR
MDM
Owner

Day 16｜Group Membership
這一天我們開始從：
帳號

走到：
權限

理解：
User
↓
Group
↓
Nested Group
↓
Permission

也區分：
Direct Membership

Recursive Membership

以及一個非常重要的觀念：
Group Membership 不等於最終 Effective Permission。

真正的 Access 可能還受到：
NTFS ACL
Share Permission
Local Group
Application RBAC

影響。
Day 17｜Account Lifecycle
開始進入：
Onboarding
Maintenance
Offboarding

同時也是第一次真正大量接觸：
修改 AD

所以流程變成：
Input
↓
Validation
↓
Preview
↓
Approval
↓
Action
↓
Verification
↓
Log

-WhatIf 在這裡非常重要。
自動化最大的危險
不是：
它太慢。

而是：
它可以非常快速地把錯誤做 100 次。

所以 Change Automation 更需要：
Scope
Validation
Approval
Verification
Audit

Day 18｜Bulk Onboarding
從：
建立一個帳號

變成：
CSV
↓
100 個新人
↓
逐筆 Validation
↓
建立 User
↓
加入 Group
↓
Verification

我們第一次正式談：
Idempotency
也就是：
Script 重跑時，不應該一直建立重複的 User。

Day 18 另外一個重要策略
新人帳號：
先建立 Disabled
↓
完成設定
↓
加入 Group
↓
確認
↓
最後 Enable

比：
先 Enable
↓
後面慢慢補

更安全。
Day 19｜Bulk Offboarding
這一天正式把：
Partial Failure
變成主角。
例如：
Disable Account Success
Group Cleanup Success
Description Success
Move OU Failed

這不能說：
全部 Success

也不能說：
什麼都沒做。

所以我們建立：
DisableStatus
GroupCleanupStatus
DescriptionStatus
MoveOUStatus
VerificationStatus
OverallStatus

最後：
Partial

這個概念到了 Day 29 已經擴大到整個 Automation Pipeline。
Day 20～23｜讓 Automation 自己運作、自己報告
Day 20｜Task Scheduler
到這裡之前：
Script

還要有人手動執行。
Day 20：
Task Scheduler
↓
powershell.exe
↓
Script

變成：
Unattended Automation
Day 20 最重要的幾個觀念
Script 不應該依賴：
Read-Host

也不要依賴：
目前登入使用者
Mapped Drive
目前 Working Directory

所以我們開始大量使用：
$PSScriptRoot

也開始明確記錄：
Current Identity
ComputerName
PowerShell Version

Exit Code
Day 20 定義：
0
Success

1
Failed

2
Partial

這個設計後來被：
Task Scheduler
CI
Daily Pipeline

一直沿用。
Day 21｜HTML Report
CSV 很適合：
Raw Data

但人不一定喜歡讀：
200 Rows CSV

所以我們使用：
ConvertTo-Html

開始做：
Summary
Problem Servers
All Servers
AD Audit

以及：
Healthy
Warning
Critical
Unknown

的視覺化。
CSV 跟 HTML 的角色
CSV
→ Raw Data

HTML
→ Human View

不是：
有 HTML 就刪掉 CSV。

Day 21 很重要的一句話
No Data 不等於 Healthy。

如果：
AD Query 沒跑成功

不能顯示：
Inactive User = 0

這會造成非常大的誤解。
應該顯示：
No Data
Collection Failed
Unknown

Day 22｜Notification
報表做得再漂亮：
沒有人打開也沒用。

所以：
Warning
Critical
Unknown

開始主動通知。
Email Subject 也不只是：
Server Report

而是：
[CRITICAL]
1 Critical / 2 Warning / 1 Unknown

讓人第一眼知道 Severity。
但通知越多不一定越好
如果每天：
同一台 Server
同一個 Critical
每天寄

很快就會：
Alert Fatigue
所以 Day 23 才會出現。
Day 23｜State Tracking
我們第一次加入：
Previous State
+
Current State

例如：
Healthy → Critical
NewAlert

Critical → Critical
ExistingIssue

Critical → Healthy
Recovery

Warning → Critical
Escalated

Healthy → Unknown
VisibilityLost

這讓 Script 從：
Stateless

變成：
Stateful

Day 23 是整個系列很大的轉折
以前：
現在是什麼？

現在：
跟上次相比發生什麼？

我們開始處理：
State
vs
Event

這其實就是 Monitoring System 很核心的思考方式。
Day 24～28｜把 Script 工程化
Day 24｜PowerShell Module
前面有很多 Function：
Write-Log
Get-ServerHealth
Get-HealthEventType
Save-HealthState

不能每一支 Script 都 Copy。
所以整理成：
SysAdminToolkit/
├── SysAdminToolkit.psd1
├── SysAdminToolkit.psm1
├── Public/
└── Private/

最後：
Import-Module SysAdminToolkit

Script 跟 Module 開始分工
Module
→ How

Script
→ Workflow

Module 負責：
怎麼查 Server？

Script 負責：
先查 Server，再查 AD，再產 Report。

這叫：
Separation of Concerns
Day 25｜Pester
Module 有了之後，新問題：
我修改 Function，怎麼知道沒把原本功能弄壞？

所以加入：
Pester

例如：
Get-HealthEventType -PreviousStatus "Critical"
-CurrentStatus "Healthy"

應該：
Recovery

Pester：
$result |
Should -Be "Recovery"

Testing 的價值
以前：
程式可以執行

我以為正常

現在：
Expected
vs
Actual

至少可以驗證：
重要 Logic 仍符合我們定義的行為。

我們也區分
Unit Test

Integration Test

Smoke Test

不要所有 Test 都：
真的連 Production AD
真的 Disable Account

測試也要控制風險。
Day 26｜Git
以前版本可能：
script.ps1
script_old.ps1
script_new.ps1
script_final.ps1
script_final2.ps1

Day 26 開始：
Git

使用：
git status
git diff
git add
git commit
git log
git show
git branch
git tag

Git 最大的價值
不是只有：
備份。

而是：
Change Traceability

也就是：
改了什麼？
誰改？
哪個 Commit？
哪一版開始壞？

.gitignore
我們也開始分：
Source

跟：
Runtime Data

例如：
Logs/
Reports/
State/
Production Input/
Secrets/

不應該全部 Commit。
尤其：
Password、Token、Private Key 不應該進 Git。

Day 27｜CI
Pester 原本還要工程師自己記得跑。
Day 27：
Git Push
↓
CI
↓
Manifest Validation
↓
Module Import
↓
Smoke Test
↓
Pester
↓
Pass / Fail

這樣：
測試不再只是好習慣，而開始變成流程的一部分。

CI 跟 Task Scheduler 不一樣
這個區分非常重要：
Task Scheduler
→ 執行 IT Operations

CI
→ 驗證 Automation Code

兩者都是 Automation。
但 Automation 的對象不同。
Day 28｜Release 與 Deployment
CI Pass 之後還不能：
直接 Copy Production

所以我們加入：
ModuleVersion
Git Tag
Artifact
SHA256
Staging
Deployment
Smoke Test
Activation
Rollback

例如：
SysAdminToolkit-1.2.0.zip

Day 28 幾個重要概念
Build Once, Deploy Many
Artifact
↓
Test
↓
Production

盡量使用同一份 Package。
Side-by-Side Versioning
SysAdminToolkit/
├── 1.1.0/
└── 1.2.0/

不要每次新版直接蓋舊版。
Version Pinning
Import-Module SysAdminToolkit
-RequiredVersion "1.2.0"

Production 明確知道自己跑哪一版。
Deployment 與 Activation 分離
Deploy 1.2.0
↓
確認
↓
Activate 1.2.0

更容易控制風險。
Day 29｜End-to-End Automation Pipeline
Day 29 沒有再加新技術。
而是第一次把所有零件：
Config
Module
Server
AD
State
Report
Notification
Log
Exit Code

全部串成：
DailyAutomation.ps1

流程：
Task Scheduler
↓
Configuration
↓
SysAdminToolkit
↓
Server Health
↓
AD Audit
↓
Current State
↓
Previous State
↓
State Comparison
↓
Event
↓
CSV
↓
HTML
↓
Notification
↓
State Commit
↓
Pipeline Summary

這就是整個系列到 Day 29 的最終實作。
30 天裡我認為最重要的觀念之一：Health Status 跟 Execution Status 要分開
例如：
SERVER01
CPU 97%

Health：
Critical

但是：
PowerShell 正確偵測
Report 成功
Notification 成功
State 成功

Automation：
Success

所以：
HealthStatus

Critical

ExecutionStatus

Success

完全合理。
如果 Email 壞掉
HealthStatus

Critical

ExecutionStatus

Partial

NotificationStatus

Failed

這才是正確的描述。
不要把：
系統有問題

跟：
Automation 有問題

混在一起。
30 天最終 SysAdmin Automation Toolkit
如果把整個專案整理成最終形式，我會長這樣：
SysAdmin-Automation/
│
├── Modules/
│ │
│ └── SysAdminToolkit/
│ │
│ ├── SysAdminToolkit.psd1
│ ├── SysAdminToolkit.psm1
│ │
│ ├── Public/
│ │ ├── Write-Log.ps1
│ │ ├── Get-ServerHealth.ps1
│ │ ├── Get-HealthEventType.ps1
│ │ ├── Save-HealthState.ps1
│ │ ├── Get-ADInactiveUserAudit.ps1
│ │ ├── Get-ADInactiveComputerAudit.ps1
│ │ ├── Get-ADGroupAudit.ps1
│ │ ├── New-DailyInfrastructureReport.ps1
│ │ └── Send-InfrastructureNotification.ps1
│ │
│ └── Private/
│
├── Config/
│ ├── Production.psd1
│ ├── Servers.example.csv
│ └── NotificationConfig.example.csv
│
├── Input/
│ ├── NewUsers.example.csv
│ └── Offboarding.example.csv
│
├── Scripts/
│ ├── DailyAutomation.ps1
│ ├── Preview-Onboarding.ps1
│ ├── Invoke-Onboarding.ps1
│ ├── Preview-Offboarding.ps1
│ ├── Invoke-Offboarding.ps1
│ ├── Invoke-CITests.ps1
│ ├── Build-Release.ps1
│ └── Install-SysAdminToolkit.ps1
│
├── Tests/
│ ├── Module.Tests.ps1
│ ├── Get-HealthEventType.Tests.ps1
│ ├── Write-Log.Tests.ps1
│ └── Save-HealthState.Tests.ps1
│
├── Reports/
│
├── Logs/
│
├── State/
│
├── Artifacts/
│
├── .gitignore
├── README.md
├── CHANGELOG.md
└── Jenkinsfile

30 天前：
PowerShell

幾條 Command

30 天後：
PowerShell

一套可以被開發、測試、部署與維護的工具。

最終 Development Pipeline
我們現在其實有兩條不同 Pipeline。
第一條管理：
Automation Code。

Engineer
↓
Feature Branch
↓
PowerShell Code
↓
Pester
↓
Git Commit
↓
Pull Request
↓
CI
↓
Manifest Validation
↓
Smoke Test
↓
Pester
↓
Quality Gate
↓
Merge
↓
Module Version
↓
Git Tag
↓
Artifact
↓
Deploy
↓
Smoke Test
↓
Activate

這是：
Development / Delivery Pipeline
最終 Operations Pipeline
第二條管理：
每天的 IT Operations。

Task Scheduler
↓
DailyAutomation.ps1
↓
Production Config
↓
SysAdminToolkit
↓
┌───────────────────────┐
│ Server Health Check │
├───────────────────────┤
│ Active Directory Audit│
└───────────────────────┘
↓
Raw Data
↓
State Compare
↓
Events
↓
HTML Dashboard
↓
Notification
↓
State Commit
↓
Pipeline Summary
↓
Engineer Review

這是：
Operations Pipeline
兩條 Pipeline 最後接在一起
Development

PowerShell Code
↓
Git
↓
Pester
↓
CI
↓
Release
↓
Artifact
↓
Deploy
↓
SysAdminToolkit 1.2.0
│
│
▼

  │
  ▼
            Operations

Task Scheduler
↓
DailyAutomation
↓
SysAdminToolkit 1.2.0
↓
Server / AD
↓
Analyze
↓
State
↓
Report
↓
Notify
↓
Engineer

做到這裡，我認為已經不只是：
PowerShell 教學。

而是：
用 PowerShell 做一個小型 IT Operations Platform。

哪些東西適合完全自動化？
這 30 天做到最後，我反而越來越覺得：
不是所有東西都應該追求「完全無人值守」。

最適合高度自動化的通常是：
Server Health Check
CPU / Memory / Disk
Service Check
Uptime
Event Log Collection
AD Inventory
Inactive User Audit
Inactive Computer Audit
Group Audit
CSV Report
HTML Report
State Comparison
Notification
Logging
Testing
CI
Package Build

因為這些通常：
大量
重複
可預測
容易驗證

哪些工作應該保留 Approval？
例如：
Disable AD User
Remove Group Membership
Move Production Object
Delete Computer Object
Delete User
高權限 Permission Change
Production Deployment

比較合理的流程仍然是：
Request
↓
Validation
↓
Preview
↓
Approval
↓
Execution
↓
Verification
↓
Audit

也就是：
自動化不等於移除所有人工判斷。

Automation 應該把人從哪裡解放出來？
不是：
不需要工程師了。

而是把工程師從：
一直 Copy Command
一直查同一個畫面
一直整理 Excel
一直重複 Server01～Server100

解放出來。
讓人去處理：
Root Cause
Risk
Architecture
Security
Exception
Business Context
Decision

所以我認為：
好的 Automation 不是把人移除，而是把人的時間留給真正需要判斷力的地方。

這 30 天我最想留下的 10 個觀念

1. 先從重複工作開始
   Automation 不一定一開始就是：
   Terraform
   Kubernetes
   Ansible

如果你每天：
做同一件事情 10 次

就值得思考 PowerShell。
2. Query First, Action Later
尤其：
AD
Production
Permission

先：
Get

再：
Set / Remove / Disable

3. No Data ≠ Healthy
   查不到

不是：
正常。

這個觀念在 Monitoring 裡非常重要。
4. Script Completed ≠ Everything Succeeded
Script 跑到最後：
不代表所有 Server 都成功。

所以需要：
Per-item Status
Stage Status
Summary

5. Error 不應該只有 Failed
   有時候：
   一半成功
   一半失敗

真正狀態是：
Partial

6. State 跟 Event 不一樣
   Critical

是 State。
Healthy → Critical

才是 Event。
這就是 Day 23 開始進入 Monitoring 思維的重要一步。
7. Configuration 跟 Logic 要分開
不要：
Server
Threshold
Email
OU

全部寫死在程式裡。
8. Production Code 要可以追蹤版本
不要再：
final
final2
final-new
final-real

Git + Version + Tag 才能真正知道：
Production 現在是哪一版。

9. Automation 本身也需要被監控
   我們原本監控 Server。
   後來發現：
   Task Scheduler
   State File
   HTML
   SMTP
   Module

也可能壞。
所以：
Automation 本身也是一個需要被維運的系統。

10. Automation 不應該取代 Judgment
    機器擅長：
    大量
    重複
    規則化

人擅長：
判斷
風險
例外
責任
決策

把兩個放在正確的位置，比追求 100% 自動化重要。
Day 1 與 Day 30 的差別
如果 Day 1 有人問：
你會 PowerShell 嗎？

可能回答：
我會一些 Get-Service、
Get-Process、
Get-ADUser。

做到 Day 30，可以回答：
我可以用 PowerShell 建立 Windows Server 與 Active Directory 的自動化維運流程，包含多台 Server 巡檢、AD 帳號與群組盤點、Onboarding / Offboarding、錯誤處理、Logging、CSV / HTML Report、Task Scheduler、State Tracking 與 Notification。

而且不只是寫 Script。
還可以繼續說：
我會把共用 Function 整理成 PowerShell Module，使用 Pester 做測試、Git 做版本控制，再透過 CI 驗證 Module，最後以版本化 Artifact 部署到 Automation Server，並保留 Rollback 與 Audit Trail。

這兩段：
差距其實非常大。

這已經開始碰到 DevOps / Platform Engineering 了嗎？
有。
因為做到後面，我們處理的已經不只是：
Windows Command

而是：
Automation
Configuration
Testing
Version Control
CI
Release
Deployment
Observability
Reliability

這些都已經開始跟：
DevOps
Platform Engineering
SRE

產生交集。
PowerShell 只是工具，真正重要的是背後的工程思維
例如：
Configuration as Data
Idempotency
Error Handling
State Management
Testing
Versioning
Release
Observability
Least Privilege
Approval Gate
Rollback

這些概念換成：
Python
Bash
Ansible
Terraform
Jenkins
Kubernetes

其實一樣存在。
所以這 30 天真正學到的不應該只是：
PowerShell Syntax。

而是：
怎麼把一個人工維運流程，逐步變成可靠的 Automation Workflow。

下一步：Ansible
PowerShell 很適合：
Windows
AD
Microsoft Environment

但如果環境開始有：
Windows
Linux
幾百台 Server

可以繼續往：
Ansible

前進。
例如我們目前：
foreach Server
↓
Invoke-Command

未來可以思考：
Inventory
↓
Playbook
↓
Multi-Host Automation

下一步：Jenkins / CI/CD
Day 27 已經開始碰到：
Jenkins
CI

之後可以再深入：
Pipeline as Code
Artifact
Environment
Approval
Deployment
Credentials

讓：
PowerShell Automation

真正進入團隊 Workflow。
下一步：Monitoring
目前我們自己做：
Healthy
Warning
Critical
Unknown

以及：
State
Event
Recovery

這些概念下一步很適合接：
Nagios
Zabbix
PRTG
Prometheus
Grafana

到時就可以更清楚理解：
Monitoring System 背後到底在做什麼。

下一步：Cloud
同樣概念可以往：
AWS
Azure
GCP

延伸。
例如：
Server Inventory
↓
Cloud Instance Inventory

Task Scheduler
↓
Cloud Scheduler / Automation

Local Report
↓
Cloud Monitoring

核心觀念其實沒有完全改變。
下一步：Platform Engineering
如果繼續往前走，會開始從：
我自己需要什麼 Script？

變成：
我怎麼建立一套讓整個工程團隊都能使用的平台與工具？

例如：
Self-Service
Standard Workflow
Reusable Module
CI Template
Deployment Pipeline
Observability
Access Control

Day 24 開始做：
SysAdminToolkit

其實就已經是非常小型的：
Platform Tooling 思維。

如果重新看這 30 天
其實一路是這樣成長的：
Day 1
我想少做一點重複工作
↓
Day 5
我可以一次處理很多 Server
↓
Day 10
我可以遠端管理
↓
Day 13
我可以查 AD
↓
Day 17
我開始做 Lifecycle Automation
↓
Day 20
我讓 Script 自己執行
↓
Day 21
我讓結果容易閱讀
↓
Day 22
我讓異常主動找人
↓
Day 23
我讓 Automation 記得上一次狀態
↓
Day 24
我把 Code 整理成 Toolkit
↓
Day 25
我開始測試自己的工具
↓
Day 26
我開始追蹤每一次修改
↓
Day 27
我開始自動驗證 Code
↓
Day 28
我開始控制 Release
↓
Day 29
我把全部串成 Pipeline
↓
Day 30
我有一套完整的
SysAdmin Automation 架構

最終架構
把整套系統再濃縮一次：
Engineer
│
▼
PowerShell Code
│
▼
Git
│
▼
Pester
│
▼
CI
│
▼
Release
│
▼
Artifact
│
▼
Deploy
│
▼
SysAdminToolkit
│
▼
Task Scheduler
│
▼
DailyAutomation
│
┌────────────┴────────────┐
▼ ▼
Windows Server AD
│ │
└────────────┬────────────┘
▼
Data
│
▼
Analyze
│
▼
Previous vs Current
│
▼
Event
│
┌────────────┼────────────┐
▼ ▼ ▼
CSV HTML Log
│
▼
Notification
│
▼
Engineer

這張圖就是：
這 30 天真正做出來的東西。

我對這 30 天最大的心得
最開始我會覺得：
Automation 就是把手動 Command 寫進 Script。

做到後面才會發現：
Command

其實只佔一小部分。
真正困難的是：
如果失敗怎麼辦？
如何知道成功？
怎麼保存結果？
怎麼避免重複通知？
誰可以執行？
什麼東西可以自動改？
Code 改壞怎麼知道？
Production 跑哪一版？
怎麼 Rollback？
誰批准 Change？

這些問題才真正決定：
一支 Script 能不能從「我自己電腦可以跑」變成「可以長期放在企業環境裡運作」。

從 Script 到 System
這也是我最後想替這 30 天做的一個總結。
第一階段：
Command

我會下指令。
第二階段：
Script

我把重複步驟自動化。
第三階段：
Tool

我開始 Function 化、Config 化。
第四階段：
Automation

我開始排程、Logging、Error Handling。
第五階段：
Workflow

我開始處理 State、Partial Failure、Notification。
第六階段：
Engineering

我開始 Testing、Git、CI、Release、Deployment。
最後：
System

我開始考慮：
Reliability
Security
Observability
Maintainability
Auditability

這才是我認為這 30 天真正完成的轉變。
30 天系列總結
如果一定要用一句話總結：
Automation 不是把一堆 PowerShell Command 串在一起，而是把原本依賴人工記憶、人工重複與人工判斷的維運流程，逐步變成可重複、可驗證、可追蹤、可維護的系統。

從：
Get-Service

開始。
最後走到：
PowerShell
×
Windows Server
×
Active Directory
×
Automation
×
Testing
×
Git
×
CI/CD
×
Monitoring Thinking

這 30 天做出來的不只是：
30 篇文章

而是一套：
SysAdmin Automation Toolkit
更重要的是，也建立了一套之後可以繼續帶到：
DevOps
SRE
Platform Engineering
Cloud
MLOps

的工程思考方式。