"Vendor" 2026-06-23
Chaos Mesh:Workflow、Scope Control 與 Steady State Probe
用 Chaos Workflow 編排多步驟實驗、用 selector 與 mode 控制 blast radius、用 StatusCheck 做 steady state probe。 2026-06-23
k6:Threshold CI Gate 與 Scenario 設計
用 threshold 把 load test 結果變成 CI pass/fail,用 scenario 讓 workload model 貼近 production traffic shape。 2026-06-23
Sloth:SLO YAML 與 Multi-burn-rate Alert 生成
用宣告式 YAML 定義 SLO,自動生成 Prometheus multi-window multi-burn-rate recording 與 alerting rules。 2026-06-23
GitHub Actions:Environment Protection 與 OIDC Cloud Auth
用 environment protection rules 做 deploy approval gate、用 OIDC 取代 long-lived cloud credential。 2026-05-19
MySQL 5.7 → 8.0 Major Version Upgrade:character set / authentication / atomic DDL 三條 paradigm 同時換軌
MySQL 5.7 → 8.0 三條 default 同時改:charset utf8 → utf8mb4、auth plugin native_password → caching_sha2_password、DDL non-atomic → atomic。本文走 Type E paradigm shift 結構、6 維 audit、4-phase upgrade、5 production 踩雷、何時不要升級。 2026-05-19
MySQL → Aurora MySQL:storage layer 轉手到 AWS、replication / HA / backup 全部 outsource
自管 MySQL → Aurora MySQL 是 Type C operational hybrid migration — wire protocol 一致、ops 責任轉到 AWS。本文走 6 維 audit(Operational High)、Aurora storage architecture 衝擊、4-phase migration、5 production 踩雷、何時維持原路線。 2026-05-19
MySQL → PlanetScale:managed Vitess + branch-based schema workflow 的 hybrid shift
自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文走 6 維 audit(Paradigm + Operational + Schema 多軸)、4-phase migration、5 production 踩雷、何時不要遷。 2026-05-19
自管 Vitess → PlanetScale:Vitess component ops outsource、加 schema workflow shift
自管 Vitess → PlanetScale 是 Type C operational hybrid — Vitess component(VTGate / VTTablet / VReplication / VSchema)ops outsource + branch workflow。本文走 6 維 audit、4-phase migration、5 production 踩雷、何時不要遷。 2026-05-19
Sibling Vendor Cross-Link 雙向性 Audit:寫 Vendor Batch 結束必跑
當寫 sibling vendor batch(A vs B)、cross-link 容易單向 — A 提 B 多次、B 沒回提 A、形成 navigation asymmetry。Case:MySQL 18 篇對 PG sibling cross-link 9 條、PG 對 MySQL cross-link 0 條。機制:寫第二個 batch 時 reference 第一個 batch 是自然行為、但 reverse direction 必須主動補。修法:vendor batch 結束跑 bidirectional link audit、`A → B` 跟 `B → A` 對比、缺一邊就補。 2026-05-19
Vendor Feature 時間敏感性:Claim Verification 必跑、寫作日期必標
寫 vendor article 時、feature limitation claim(『不支援 X』『最多 Y』『預設 Z』)有時間敏感性 — vendor 持續演進、寫作後 N 個月可能 invalidate 整段 audit 邏輯。Case:PlanetScale FK 不支援是 2022 年的事實、2023 末 Vitess 18 加 FK 支援、寫作時若不 verify、Phase 1 audit「FK audit + 全 drop」整段過時。機制:LLM training cutoff vs vendor changelog 速度差、且 LLM 預設不標 claim 的時間性。修法:每篇 vendor article 標 *Last verified* date、limitation claim 必要時加 *as of N* 註、claim 反轉 invalidates 整段 audit 時必須重寫不是修補。 2026-05-20
資料庫 Vendor 文章撰寫規格
把 PostgreSQL 與 MySQL batch 的正文經驗整理成資料庫 vendor overview、deep article 與 migration playbook 的撰寫規格 2026-05-19
Atlassian Statuspage → Instatus:status page 成本下降、但 compatibility audit 不能跳
Atlassian Statuspage → Instatus 是 Type B drop-in migration、6 維 audit 全 Low;典型情境是從 Statuspage Business / Enterprise 降到 Instatus Pro / Business、但 savings 取決於 subscriber、SSO、audit 與 SLA report 需求。本文走 compatibility audit prefix(subscriber channel 完整度 / SAML SSO / audit log / metrics integration / SLA report / API parity)、4 階段 cutover(DNS TTL + parallel run)、5 個 production 踩雷(SSO tier 選錯、metrics 來源整合斷、subscriber import format / SLA report 缺、custom CSS 不完全相容)、何時不要切(enterprise compliance / 強 Atlassian 整合) 2026-05-19
JMeter → k6:k6 不是 JMeter 的「script 版本」、是 VU model 取代 thread model
JMeter → k6 是 Type E paradigm shift、不是把 .jmx XML 翻成 JavaScript — VU (virtual user) model 跟 thread group model 是兩種對「使用者行為」不同的建模方式。本文走 6 維 audit(Schema High / Paradigm High / Operational Medium)、釐清反向定義、4-phase partial migration(多數 org 停 Phase 2-3 hybrid)、5 production 踩雷(thread group 翻譯失真 / arrival rate vs concurrent VU 混淆 / protocol gap / 結果 schema 改 / CI integration 重做)、protocol gap(JDBC / JMS / LDAP 在 k6 沒原生對應)、何時不要切 2026-05-19
PagerDuty → incident.io:「On-call」是個 retconned word、同名不同 contract
PagerDuty → incident.io 不是 schema translation — 兩家的「on-call」字面相同、contract 不同(alert routing vs IR coordination + Slack-native + retrospective)。本文走 Type E paradigm shift、6 維 audit 顯示 paradigm / schema / operational 三軸 High、用 4-phase partial migration(不收斂、Phase 1-2 多數 org 停留)、5 個 production 踩雷(雙系統 state drift / severity 翻譯失真 / schedule layer 漏 / Slack channel 過載 / retrospective 斷層)、跟 PagerDuty Process Automation / AIOps 沒對應的 capability gap 2026-05-19
PagerDuty → Opsgenie:Atlassian 全家桶整合 vs Opsgenie 2027 EOL 的 vendor consolidation 取捨
PagerDuty → Opsgenie 是 Type A phased schema translation、但 Atlassian 已宣布 Opsgenie 2027-04 EOL — 這條 migration 只在 Atlassian-heavy org + 明確 JSM unification roadmap 下成立、本質是 PD → Opsgenie → JSM Cloud 的雙 hop migration。本文走 6 維 audit(Schema Medium-High 其他 Low)、PagerDuty ↔ Opsgenie ↔ JSM field mapping 對照、5 production 踩雷(escalation step / Heartbeat 缺對應 / integration key dedup 重設 / schedule 時區 / Atlassian Identity SSO 整合)、何時直接走 PD → JSM 跳過 Opsgenie 2026-05-19
Pyroscope → Datadog Continuous Profiler:profiling deployment lifecycle 各階段 operational ownership 轉手
Pyroscope → Datadog Continuous Profiler 是 Type C operational hybrid migration — pprof data model 接近、profile lifecycle 五階段(install / instrument / ingest / query / cost)的 ops ownership 從 self-host 轉到 SaaS。本文走 6 維 audit(Operational High 其他 Low)、4-phase migration(operational audit + agent parallel + tag reconcile + cutover)、5 production 踩雷(agent 重複 overhead / tag schema 不一致 / trace_id correlation 斷 / cost 突增 / retention 政策變動)、何時保留 Pyroscope(資料主權 / 內網 / OSS-first / cost sensitive) Tarragon (CC BY 4.0) | 使用 hugo 製作