Tarragon

"Vendor"

• 2026-10-28 JMeter 在本機跑負載測試的實測紀錄：Docker image、test plan 的元件、CSV Data Set、CLI mode 與 JTL、dashboard 與 statistics.json、JMeter 之外的門檻判定、remote testing 的 client 與 server 要在本機用 Docker 照一次實測跑 JMeter：建 image、寫 test plan、從 CSV 餵測試資料、用 CLI mode 跑出 JTL 與 dashboard、讀 statistics.json 判定門檻、開 client 與多台 server 做 remote testing 時讀；也用在 sample 失敗了 exit code 還是 0、CSV 裡某些值從來沒被請求到、-J 傳的屬性在 server 上沒有作用、-o 回報資料夾不是空的時候
• 2026-10-28 JMeter 在容量探測的用法：thread group 固定的負載變數、逐級加壓、knee 的判讀、施壓端與分散施壓的檢查、多 protocol 的涵蓋範圍與排查順序 用 JMeter 找飽和點時的判斷：thread group 與 timer 量的是哪一種負載模型、Open Model Thread Group 的逐級加壓、從 dashboard 判讀 knee、施壓端與 TLS 連線的失真、分散施壓，以及容量結論要附的條件
• 2026-10-28 JMeter 在效能 regression gate 的用法：JMeter 之外的門檻判定、逐筆 assertion 與統計門檻的分工、thread group 的負載模型、施壓端設定與基準的可比性、PR 與 nightly 的分工、證據保存與 gate 失敗的排查順序 用 JMeter 實作效能 regression gate 時的判斷：門檻判定放在 JMeter 之外的哪一段、逐筆 assertion 與分佈門檻的分工、負載模型與施壓端設定怎麼影響前後兩版的比較、要保存的執行條件，以及 gate 失敗時怎麼把誤判和真正的退化分開
• 2026-10-28 Locust 在本機跑負載測試的實測紀錄：受測服務、locustfile、headless 執行與 CSV、內建的 exit code、quitting 事件裡的門檻判定、--reset-stats 與 on_start、master 與 worker 的分散執行 要在本機用 Docker 照一次實測跑 Locust：寫 locustfile、headless 執行、讀終端機的統計表與 CSV、在 quitting 事件裡判定延遲門檻、開 master 與多個 worker 分散執行時讀；也用在受測服務變慢而 exit code 還是 0、加了 --reset-stats 之後登入請求還在統計裡、master 回報 worker failed to send heartbeat 的時候
• 2026-10-28 Locust 在容量探測的用法：closed model 下的逐級加壓、吞吐量與延遲的換算、pacing 的上限、worker 的檢查與排查順序 Locust 只有 closed model 時找飽和點的判斷：逐級增加使用者、從每秒 task 數與延遲換算受測服務的狀態、到達率型服務的延遲低估與 pacing 的上限、worker 與 client 的排除條件，以及容量結論的寫法
• 2026-10-28 Locust 在效能 regression gate 的用法：exit code 與門檻判定、預熱與 on_start 的請求、closed model 下的比較、custom client 回報的請求範圍、PR 與 nightly 的分工、證據保存與 gate 失敗的排查順序 用 Locust 實作效能 regression gate 時的判斷：內建 exit code 之外的門檻怎麼在 quitting 事件裡判定、登入與預熱的請求怎麼混進統計、closed model 讓退化落在延遲還是吞吐量，以及 gate 失敗時怎麼把誤判和真正的退化分開
• 2026-10-27 Gatling 在容量探測的用法：open model 的逐級加壓、knee point 的判讀、施壓端的檢查、feeder 資料的分佈與排查順序 用 Gatling 找受測服務飽和點時的判斷：逐級加壓的兩種注入寫法與各自適用的階段、report 的四張圖怎麼換算成受測服務的狀態、施壓端要先排除的資源與 OSS、Enterprise 的分散施壓、feeder 資料怎麼讓容量估高、讀寫高峰錯開時的 scenario 寫法，以及容量結論要附的執行條件
• 2026-10-27 Gatling 在效能 regression gate 的用法：assertion 的門檻、ramp-up 與量測區間、注入模型、PR 與 nightly 的分工、證據保存與 gate 失敗的排查順序 用 Gatling 實作效能 regression gate 時的判斷：assertion 對應哪一種判讀方法、OSS 怎麼做出相對門檻與跨次比較、預熱的請求怎麼處理、注入模型怎麼影響前後兩版的比較、Gatling 在 CI 的哪幾條路徑跑、要保存哪些執行條件，以及 gate 失敗時怎麼把誤判和真正的退化分開
• 2026-10-22 Meta Pixel 與 Conversions API：廣告平台轉換追蹤的瀏覽器端與伺服器端 Meta Pixel 在頁面上送出的標準事件與它的資料消費者、瀏覽器端事件被攔截的路徑、Conversions API 從伺服器補送同一批事件的必填欄位，以及兩路並送時以 event_id 去重與用 Test Events 驗證的方式
• 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-10-22 Google Tag Manager：追蹤碼的部署層、資料層約定與發布治理 GTM 容器在頁面上承擔的部署責任、資料層作為前端與行銷之間的事件約定、預覽模式與版本發布的驗證方式、自訂 HTML 代碼帶來的安全與效能成本，以及伺服器端代碼管理改變的資料路徑
• 2026-06-23 GitHub Actions：Environment Protection 與 OIDC Cloud Auth 用 environment protection rules 做 deploy approval gate、用 OIDC 取代 long-lived cloud credential。
• 2026-10-22 Meta Pixel 實測頁：在瀏覽器裡觀察 fbq 呼叫、送出的請求與寫下的 cookie 在這一頁按按鈕載入 Meta Pixel、送 PageView、ViewContent 與帶 eventID 的 Purchase，並用頁面上的面板對照每個呼叫送出的請求參數，以及 _fbp 與 fbclid 帶出的 _fbc cookie
• 2026-10-22 Google Tag Manager 實測頁：在瀏覽器裡觀察容器載入、資料層事件與代碼送出的請求 在這一頁按按鈕載入 GTM 容器、往資料層推 purchase 事件，並用頁面上的面板對照 window.dataLayer 的內容、容器載入的代碼與它們送出的請求
• 2026-10-22 用 Playwright 擷取追蹤碼請求：擷取方式、記錄欄位與各次結果 以 Playwright 操作 Meta Pixel 與 GTM 實測頁、記錄各家 script 實際送出的請求與 cookie 的方式，結果檔記錄的欄位與它們的用途，擷取用的測試帳號，以及每一次擷取觀察到的事件請求形式、cookie 與請求參數的對應、無頭瀏覽器下的差異與 script 自動送出的事件
• 2026-10-23 追蹤資產的歸屬：Meta、GTM 與 GA4 的擁有層級、權限分級與移交方式 Meta Pixel 的資料集、GTM 容器與 GA4 資源（property）各自屬於哪一層的擁有者，三家的權限怎麼分級，哪些資產能換到另一個擁有者底下，以及公司自營、委託代理商、換代理商與事業轉手時的歸屬安排
• 2026-10-13 Prometheus 指標的視覺化工具：視覺化層的責任，與內建介面、Grafana、Perses、Kibana／OpenSearch Dashboards、託管服務的取捨 自架 Prometheus 之後把指標畫成常駐畫面的那一層承擔哪些責任（查詢與呈現、儀表板定義的保存、存取控制、告警規則放在哪一層、多種資料來源、授權與資源），Grafana 逐項對照這些責任，內建介面、Perses、Kibana／OpenSearch Dashboards 與託管服務各自的定位與成立的前提，以及前提改變時改用哪一個
• 2026-10-13 多台主機的指標收集：讀取架構、主機標籤、目標清單、監控主機的位置與主機消失的偵測 服務分到多台主機之後，Prometheus 怎麼讀到每一台：exporter 的部署位置與連接埠、中央直接讀取與各主機先收再推送的架構、代表主機的 host 標籤加在哪裡、目標清單由什麼產生，主機停掉與主機從清單上消失各自怎麼偵測，以及監控元件放在哪一台、compose 檔怎麼依主機角色拆開；附在單機上模擬第二台主機的驗證
• 2026-10-13 Grafana 的對外存取：SSH 通道或 VPN、經由應用入口轉送的問題、監控主機上的反向代理，與登入保護和認證的位置 Grafana 只綁本機之後，讓其他人看到它的做法：看的人能不能經由 SSH 或 VPN 連進來、有沒有固定的來源網段時各自的存取方式，SSH 通道的連法，應用入口 Nginx 加上 Grafana 的轉送之後的兩個問題，監控主機上專用反向代理的 TLS、WebSocket、GF_SERVER_ROOT_URL 與來源限制，以及 Grafana 登入失敗的帳號鎖定與認證放置
• 2026-10-13 Alertmanager 的通知管道：路由樹與分組、webhook 與 ntfy、email 與 Slack、私密網址的檔案、心跳與通知送不出去的偵測 Alertmanager 從只在網頁上看告警，到依嚴重度送到手機與信箱：路由樹怎麼決定一則告警送到哪裡、分組與 group_wait、group_interval、repeat_interval 各控制什麼，以 webhook 接 ntfy 推播與它的訊息範本，email 與 Slack 的設定，私密網址為什麼要放在檔案裡（設定檔不展開環境變數），以及 Watchdog 心跳與通知送不出去時的偵測
• 2026-10-14 第三方心跳監看與外部探測服務：挑選條件、healthchecks 的 ping 與 /fail、Alertmanager 的接法與演練 以第三方服務當作監控主機失效域以外的觀察者：心跳監看服務的挑選條件與送出的告警資料留在哪裡，healthchecks 的 ping 網址、週期與寬限、/fail 與自架和託管版的回應差異，Alertmanager 送心跳與送失敗通知的 receiver 與路由順序、驗收與暫停，停掉 Alertmanager 的演練，以及外部探測服務的挑選條件
• 2026-10-13 在 Kubernetes 上接上監控：kube-prometheus-stack 的元件、ServiceMonitor 與 PrometheusRule 的選取、節點標籤、儀表板 sidecar、Alertmanager 的預設路由、控制平面的讀取與單節點叢集的資源用量 在 Kubernetes 上以 kube-prometheus-stack 接上監控：chart 裝了哪些元件與 CRD，讀取對象與告警規則改以 ServiceMonitor、PrometheusRule 宣告之後由誰轉成 Prometheus 的設定，release 標籤決定哪些宣告會被選中，主機標籤改成節點標籤，儀表板經由 ConfigMap 與 sidecar 載入，Alertmanager 預設不送任何通知，以及控制平面元件只綁本機時讀不到的原因、單節點叢集上的資源用量與記憶體不足時的表現
• 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 結構、schema 到 topology 的 diff audit、從 pre-check 到 paradigm 遷移的升級流程、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。本文涵蓋差異維度盤點（operational 為主）、從 Aurora 作為 external replica 到退役自管 MySQL 的階段切換、parameter group / IAM auth / Aurora-only feature / reader endpoint / 跨 region 寫入模型的踩雷，以及何時維持原路線。
• 2026-05-19 MySQL → PlanetScale：managed Vitess + branch-based schema workflow 的 hybrid shift 自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文涵蓋差異維度盤點（schema workflow、operational、schema 多軸）、從 FK 行為驗證到 write cutover 的階段切換與多數組織停留的 hybrid 狀態、cross-shard FK / Deploy Request 心智模型 / branch 不帶資料 / stale branch / 無 SUPER privilege 的踩雷，以及何時不要遷。
• 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。本文涵蓋差異維度盤點、從 topology 盤點到寫入切換與退役自管 Vitess 的階段切換、custom Vindex / branch workflow 訓練 / SUPER privilege / 連線上限 / per-row 計費的踩雷，以及何時不要遷。
• 2026-05-20 資料庫 Vendor 文章撰寫規格 把 PostgreSQL 與 MySQL 兩組文章的正文經驗整理成資料庫 vendor overview、deep article 與 migration playbook 的撰寫規格
• 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-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）