TC Data, Floor 9, Victory Tower, 12 Tan Trao, Tan Phu Ward, District 7, Ho Chi Minh City (2026)

28/07/2026

🤝 Staging là đứa em ngoan. Production là ông anh từng trải.

Có một sự thật mà ai làm phần mềm rồi cũng sẽ nhận ra: Staging và Production trông thì giống nhau, nhưng cách vận hành lại hoàn toàn khác.
Chúng là hai anh em cùng cha khác… tính cách. 😆
⸻

🟢 Staging là đứa em út.
Hiền. Dễ tính. Mình đưa gì nó cũng nhận.
💬 “Deploy hả? Được anh.”
💬 “Build pass chưa? Pass rồi anh.”
💬 “Có lỗi không? Không anh. Em chạy mượt lắm.”
Dashboard xanh lè. Log sạch như mới cài máy.
Mình gật gù:
“Code của mình cũng ổn áp phết.”
Thế là bấm Deploy Production.
Đứng dậy đi pha ly cà phê. ☕
⸻

🔴 Chưa kịp uống ngụm đầu tiên…
Ông anh Production hắng giọng:
“Ai cho mày vào?”
Mình giật mình:
“Ủa… em vừa chạy bên Staging mà?”
Production nhếch mép:
“Bên đó là bên đó.”
Rồi ổng bắt đầu đọc tội.
❓ API Key đâu?
❓ Environment Variable này ai xóa?
❓ Build bằng Node 18 hả? Tao Node 20.
❓ Package này khác version.
❓ Connection String đâu?
❓ Database Schema của tao cập nhật từ tuần trước rồi.

💥 Mỗi câu nói là một nhát chí mạng.
⸻

💻 Mình bắt đầu…
🔹 Mở DevOps.
🔹 Mở Portal.
🔹 Mở SSH.
🔹 Mở Teams.
🔹 Mở luôn Google. 😅
Đến lúc xong xuôi thì…
🕖 7 giờ tối.
⸻

💡 Điều thú vị là…
Production chưa bao giờ nói sai.
Nó cũng chẳng ghét developer.
Nó chỉ từ chối giả vờ rằng mọi thứ đều ổn.
Staging thì khác.
Nó giống đứa em dễ tính, lúc nào cũng chiều ý bạn:
“Được rồi, cứ chạy đi. Tôi cân được.”
Còn Production giống ông anh đã va chạm đủ nhiều để không dễ dàng cho qua mọi thứ.
Với Production, không tồn tại khái niệm: “Chạy tạm cũng được.”
Hoặc đúng.
Hoặc không chạy.
⸻

😅 Rồi mình nhận ra một điều hơi đau lòng.
Thủ phạm không phải Staging.
Cũng chẳng phải Production.
👉 Thủ phạm là thằng ngồi trước màn hình.
Là mình.
• Mình quên thêm Environment Variable.
• Mình sửa config ở Staging nhưng quên Production.
• Mình update package ở local nhưng server vẫn bản cũ.
Mình nghĩ:
“Chắc cũng giống nhau thôi.”
Production đáp lại:
“Mày nghĩ sai rồi.”
⸻

🎯 Sau vài lần được cuộc đời “đào tạo miễn phí”, mình rút ra một bài học:
Đừng cố làm cho Staging và Production trông có vẻ giống nhau.
Hãy làm cho chúng thật sự giống nhau.
✅ Infrastructure as Code
✅ Docker
✅ CI/CD
✅ Quản lý cấu hình tập trung
✅ Version được cố định
✅ Tự động hóa deployment
✅ Một checklist tử tế trước khi bấm nút Deploy
Nghe thì nhiều việc. Nhưng vẫn nhẹ nhàng hơn ngồi debug Production lúc 5 giờ chiều thứ Sáu, trong khi cả công ty đã lên kế hoạch đi nhậu. 🍻
⸻

💬 Có người từng nói:
“Code chạy trên máy tôi.”
Production chỉ cười.
“Ừ. Nhưng đây đâu phải máy của mày.”
Và đó là lúc câu chuyện bắt đầu.

24/07/2026

💡 Trước khi biết đến Delta Table, mình luôn nghĩ rằng nếu lỡ overwrite dữ liệu thì coi như… xong. 😅

Cho đến khi làm việc với Microsoft Fabric và Delta Lake, mình mới biết đến một tính năng cực kỳ hữu ích: Time Travel. ⏳
Hiểu đơn giản, mỗi lần dữ liệu trong Delta Table được cập nhật (INSERT, UPDATE, DELETE, MERGE…), Delta sẽ tự động lưu lại lịch sử của bảng dưới dạng các version.
Điều đó có nghĩa là mình có thể:
✅ Xem dữ liệu ở một thời điểm trong quá khứ
SELECT *
FROM sales VERSION AS OF 5;
Hoặc theo timestamp:
SELECT *
FROM sales TIMESTAMP AS OF '2026-07-01 10:00:00';

😅 Có lần mình overwrite nhầm một bảng trong môi trường test.
Thay vì phải restore backup hoặc chạy lại pipeline mất hàng tiếng, mình chỉ cần đọc lại version trước đó và recover dữ liệu trong vài phút.
💡 Đó là lúc mình thấy Time Travel thực sự đáng giá.
⸻

Ngoài Time Travel, Delta Table còn có rất nhiều điểm mạnh:
🚀 ACID Transaction giúp tránh tình trạng dữ liệu bị lỗi khi nhiều job ghi cùng lúc.
🔄 Hỗ trợ MERGE rất mạnh, cực kỳ phù hợp cho Incremental Load và CDC.
📈 Performance tốt nhờ metadata, partition pruning và file compaction.
🛡️ Schema Enforcement & Schema Evolution giúp kiểm soát thay đổi cấu trúc dữ liệu.
📜 Lưu lịch sử thay đổi với DESCRIBE HISTORY, rất hữu ích khi audit hoặc debug pipeline.
⸻

🎯 Với mình, Delta Table không chỉ là một định dạng lưu trữ, mà còn là nền tảng giúp việc xây dựng Data Lake trở nên đáng tin cậy hơn.
Nếu bạn đang sử dụng Microsoft Fabric hoặc Databricks mà vẫn lưu dữ liệu dưới dạng Parquet thông thường, mình nghĩ Delta Table là một nâng cấp rất đáng để thử.

💬 Bạn đã từng dùng Time Travel để “cứu” một pipeline hay recover dữ liệu chưa? Chia sẻ cùng mình nhé! 😄

22/07/2026

Có một điều mà mình tin rất nhiều anh em làm BI/Data từng gặp:
Nhận task migration dashboard hoặc database.

Nghe thì khá đơn giản:
Copy data ✔️
Rebuild report ✔️
Publish ✔️
…cho đến khi 👀

📌 Bạn phát hiện một measure có cái tên rất “thơ”: Final KPI v3 Latest_New_2
Không ai biết nó đang tính gì.
• Stored Procedure dài hơn 2.000 dòng.
• Dashboard có hơn 100 measure.
• Và người xây dựng trước đó… đã nghỉ việc từ năm ngoái.
😅 Lúc đó cảm giác chẳng khác nào đang chơi game giải đố:
“Nếu sửa chỗ này… Production có nổ không?”
⸻

💡 Điều thú vị là, phần khó nhất của migration lại không phải viết code.
Mà là… đi tìm lịch sử.
🤔 Vì sao bảng này được tạo ra?
🤔 Business logic nằm ở đâu?
🤔 Data flow chạy như thế nào?
🤔 Tại sao phải cộng thêm 3%?
🤔 Tại sao filter country lại đặt ở đây?
Nếu không có tài liệu, mỗi developer gần như phải làm… “nhà khảo cổ dữ liệu” bằng cách: Đọc SQL, DAX, Pipeline,... Rồi… đoán. 😅
⸻

🎯 Sau vài dự án, mình rút ra một bài học rất đáng giá:
Code giúp hệ thống chạy. Documentation giúp hệ thống sống lâu.
📝 Một sơ đồ architecture.
📝 Vài trang mô tả business logic.
📝 Một sơ đồ data flow.
Tưởng chỉ mất thêm một buổi để viết, nhưng lại tiết kiệm hàng chục giờ cho người tiếp quản sau này.
⸻

🚀 Migration rồi sẽ kết thúc.
Dashboard sẽ được thay mới.
Database cũng sẽ được nâng cấp.
Nhưng một bộ tài liệu tốt sẽ luôn là “người đồng đội thầm lặng”, giúp cả team làm việc nhanh hơn, tự tin hơn và giảm rất nhiều rủi ro.

💭 Lần tới khi hoàn thành một dashboard hay pipeline, có lẽ đừng chỉ commit code.
Hãy commit luôn cả câu chuyện đằng sau nó.

20/07/2026

🚀 Chuyện anh OLTP và chị Lakehouse: Databricks vừa “rủ” hai người về chung một nhà

Lâu nay, thế giới dữ liệu có hai "thế giới" tách biệt
⚡ OLTP (Online Transaction Processing) – xử lý giao dịch trực tuyến: nhanh, tối ưu cho đọc/ghi từng giao dịch với độ trễ thấp (ví dụ: Database Postgres).
📊 Lakehouse/OLAP (Online Analytical Processing) – xử lý phân tích: lưu trữ lượng dữ liệu lịch sử khổng lồ, mạnh về scan và tổng hợp, nhưng nhưng không tối ưu tra cứu nhanh từng dòng.
👉 Muốn hai bên “nói chuyện” với nhau, chúng ta thường phải thông qua ETL (Extract – Transform – Load):các pipeline sao chép, biến đổi rồi nạp dữ liệu qua lại - tốn thời gian, tốn chi phí và dữ liệu luôn trễ một nhịp.
(Ảnh đính kèm 1)
⸻

💡 Databricks đang giải bài toán này bằng Lakebase — một dịch vụ Postgres Serverless được tích hợp trực tiếp vào Lakehouse, ra mắt từ 06/2025.
Một vài điểm nổi bật:
💤 Scale-to-zero
• Không có workload thì tự “ngủ”, không tính phí compute, tải tăng thì tự động scale.
🌱 Instant Branching
• Tạo bản sao zero-copy của database chỉ trong vài giây để dev thử nghiệm an toàn.
🛠️ Chuẩn PostgreSQL mở
• Hoạt động với pgAdmin, DBeaver, pgvector…, quản trị tập trung thông qua Unity Catalog.
(Ảnh đính kèm 2)
⸻

📢 Về GA (General Availability) - phát hành chính thức rộng rãi:
☁️ Lakebase GA trên AWS vào đầu 02/2026.
☁️ Tiếp theo là Azure vào đầu 03/2026.
📈 Từ khi ra mắt, tốc độ adoption tăng hơn gấp đôi so với chính sản phẩm Data Warehouse của Databricks.
(Ảnh đính kèm 3)
⸻

🚀 Mới nhất
Tại Data + AI Summit (16/06/2026), Databricks công bố tầm nhìn LTAP (Lake Transactional/Analytical Processing).
Ý tưởng khá thú vị:
• Giao dịch (Transactional) và Phân tích (Analytical) cùng hoạt động trên một bản dữ liệu trong Lakehouse.
• Dùng chung lớp governance Unity Catalog.
• Bớt phụ thuộc vào việc sao chép dữ liệu giữa OLTP và OLAP thông qua ETL.

⚠️ Tuy nhiên, cần lưu ý rằng LTAP hiện mới ở mức công bố tầm nhìn. Một vài mảnh ghép vẫn đang ở giai đoạn Beta - tức đang là hướng đi, chưa hoàn thiện 100%.
Điều đó cũng có nghĩa:
❌ ETL chưa biến mất.
✅ Nhưng vai trò của ETL nhiều khả năng sẽ thu hẹp dần trong tương lai.
⸻

💭 Góc nhìn cho dân Data Engineer
Ranh giới giữa giao dịch và phân tích đang ngày càng mờ đi. Rất đáng để theo dõi và thử sớm.
Mình đang thử Lakebase trong một PoC gần đây và thấy khá thú vị.
👉 Anh em đã có dịp trải nghiệm Lakebase chưa? Chia sẻ cảm nhận cùng mình nhé!

17/07/2026

💡 [TC DATA x Power BI Tips] – Power BI Modeling MCP: Khi Claude không chỉ “tư vấn” mà còn tự tay chỉnh sửa Semantic Model của bạn

1. Power BI Modeling MCP là gì?
MCP (Model Context Protocol) đóng vai trò như một “cầu nối” giữa hai bên:
Claude — vốn chỉ có khả năng tư duy và viết logic, không thể tự tay chỉnh sửa bất cứ thứ gì.
Power BI Desktop — nơi sở hữu toàn bộ table, measure, relationship thật nhưng không có khả năng "suy luận" độc lập.
🔗 MCP Server kết nối hai bên thông qua Local XMLA Endpoint, cho phép Claude: đọc trực tiếp cấu trúc model đang mở và thực thi thay đổi: tạo measure, chạy DAX query, kiểm tra relationship… tất cả không cần rời khỏi khung chat.

2. Cách thiết lập cho Claude Account
(Ảnh đính kèm)

3. Ứng dụng thực tế cho công việc Data/BI
🔍 Debug measure phức tạp: khi một measure cho kết quả sai hoặc chạy chậm bất thường, thay vì dò từng dòng DAX bằng mắt, có thể để Claude tự truy vấn cấu trúc model, đối chiếu relationship và chỉ ra chính xác điểm gây lệch granularity hoặc filter context.
🛠️ Truy vết lỗi chất lượng dữ liệu tận gốc: với các trường hợp một entity (mã khách hàng, mã sản phẩm) bị trùng lặp do lỗi ETL, Claude có thể chạy DAX query trực tiếp trên model thật để khoanh vùng bản ghi bất thường, thay vì phải export dữ liệu ra rồi mô tả lại bằng lời.
⚡Dựng nhanh các measure có logic phức tạp: với những yêu cầu dạng Top N động theo Field Parameter, routing dữ liệu qua bảng trung gian, hay time intelligence nhiều tầng — Claude có thể viết và đưa thẳng measure vào model, người dùng chỉ cần kiểm tra lại trên visual.
⸻

⚠️ Một vài điểm cần lưu ý
🔸 MCP hiện chỉ tác động đến lớp model (table, measure, relationship). Phần report layer (visual, layout, formatting…) vẫn là công việc thủ công.
🔸 Model của bạn càng lớn (nhiều table, measure và relationship), Claude càng cần nhiều token để phân tích.

💡 Vì vậy, nên sử dụng Claude Pro (hoặc cao hơn) để tránh cảnh đang debug measure thì Claude… “hết hơi giữa chừng”. 😆

15/07/2026

🎨 Power BI Theme JSON – Bước đầu để chuẩn hóa giao diện báo cáo

Hồi mới làm Power BI, mình cũng như nhiều bạn: chỉnh màu từng biểu đồ, đổi font từng tiêu đề, rồi căn chỉnh từng visual sao cho nhìn “ổn áp” nhất. Với một vài report thì không sao, nhưng khi số lượng báo cáo nhiều lên, hoặc có nhiều người cùng làm, thì bắt đầu thấy... hơi mệt 😅.
Mỗi report một kiểu, mất thời gian mà cũng khó giữ được sự nhất quán.
💡 Và đây là lúc Power BI Theme JSON phát huy tác dụng.
⸻

📖 VẬY, THEME JSON LÀ GÌ?
Hiểu đơn giản, Theme JSON giống như một "bộ quy chuẩn giao diện” cho toàn bộ report của bạn. Thay vì phải chỉnh từng visual, bạn chỉ cần define một lần các thứ như:
🎨 Màu sắc (Color Palette)
🔤 Font chữ
🖼️ Background
🏷️ Tiêu đề
📊 Data Labels
📈 Style của các loại biểu đồ
Sau đó chỉ cần Import file JSON vào Power BI là toàn bộ report sẽ tự động áp dụng cùng một phong cách. ✅
⸻

🚀MÌNH NÊN BẮT ĐẦU NHƯ THẾ NÀO?
1️⃣ Xác định phong cách trước
Trước tiên hãy nghĩ xem bạn muốn report của mình trông như thế nào:
🎨 Màu chủ đạo là gì?
🔤 Sử dụng font nào?
🏢 Có Brand Guideline của doanh nghiệp không?
💡 Nếu chưa biết bắt đầu từ đâu, bạn có thể sử dụng tool generate theme, ví dụ:
Power BI Theme Generator (BIBB) 👉 Chỉ cần nhập palette màu là công cụ sẽ generate JSON cho bạn luôn.
(Ảnh 1)

2️⃣ Tinh chỉnh file JSON
Sau khi có file cơ bản:
💻 Mở bằng VS Code (hoặc IDE bất kỳ).
⚙️ Chỉnh thêm các thuộc tính nâng cao nếu muốn.
(Ảnh 2)
💡 Tip: Đây cũng là phần AI hỗ trợ rất tốt.
Bạn có thể nhờ AI:
• Giải thích từng thuộc tính/cấu trúc trong JSON.
• Generate nhanh config theo ý mình.

3️⃣ Import vào Power BI
Trong Power BI Desktop:
View → Themes → Browse for themes
➡️ Chọn file JSON là xong
(Ảnh 3)

4️⃣ Tái sử dụng
Một file Theme JSON có thể:
🔄 Dùng lại cho nhiều report.
👥 Chia sẻ cho cả team.
📐 Trở thành Design Standard chung cho toàn bộ dashboard.
⸻

⭐ VÌ SAO NÊN DÙNG FILE THEME JSON?
Nếu team bạn có:
📊 Nhiều dashboard.
👨‍💻 Nhiều người cùng develop
Thì việc xây dựng Theme JSON ngay từ đầu sẽ giúp:
✅ Tiết kiệm rất nhiều thời gian format.
✅ Đồng nhất giao diện giữa các báo cáo.
✅ Dễ update Brand (chỉ cần sửa một file là xong).
⸻

📚 Nếu muốn tìm hiểu thêm, bạn có thể tham khảo:
🔹 Microsoft Report Theme JSON Schema (tài liệu chính thức từ Microsoft)
https://github.com/microsoft/powerbi-desktop-samples/blob/main/Report%20Theme%20JSON%20Schema/README.md
🔹 Power BI Studio – Complete Guide to Theme JSON & Design Systems
https://www.powerbistudio.com/blog/power-bi-themes-design-systems-json-templates-complete-guide

09/07/2026

🔍 MICROSOFT PURVIEW: CHIẾC “KÍNH LÚP” CỨU RỖI SỰ KHỦNG HOẢNG CỦA DATA GOVERNANCE

🤔 Có bao giờ bạn rơi vào cảnh: Sếp hỏi một chỉ số tài chính lấy từ đâu, bạn mất cả ngày lội ngược dòng qua 5 tầng pipeline, 10 cái database để tìm câu trả lời?
💥 Hoặc một ngày đẹp trời, ai đó đổi tên một cột ở nguồn và… bùm, toàn bộ hệ thống Power BI phía sau sập đổ mà không ai biết lý do?

Nếu hệ thống dữ liệu của bạn đang là một “ma trận” như vậy, thì đã đến lúc mang Microsoft Purview vào cuộc chơi.
Hãy nhìn Purview dưới góc nhìn thực tế nhưng không kém phần thú vị qua 3 tính năng cốt lõi:

📚 Data Catalog – “Google Search” dành riêng cho doanh nghiệp
Thay vì phải đi hỏi khắp nơi:
❓ “Bảng này chứa gì?”
❓ “Ai là người quản lý?”
Purview tự động Scan toàn bộ hệ thống từ On-premises lên Cloud để phân loại và gắn nhãn dữ liệu. Bạn chỉ cần gõ từ khóa, Purview sẽ chỉ ra chính xác vị trí của data asset đó nằm ở đâu chỉ trong vài nốt nhạc.
⸻
🗺️ Data Lineage – Bản đồ “gia phả” của dữ liệu
Đây chính là tính năng cứu mạng các Data Engineer.
Nhờ Apache Atlas API và các bộ scan tự động, Purview vẽ ra một bản đồ kết nối trực quan:
➡️ Dữ liệu đi từ đâu
➡️ Qua những Stored Procedure nào
➡️ Biến đổi ra sao ở tầng Silver/Gold
➡️ Kết thúc ở Dashboard nào
💡 Nhìn vào Lineage, bạn sẽ biết ngay: “Nếu mình sửa chỗ này, những ai ở hạ nguồn sẽ chịu trận?”
⸻
🛡️ Data Classification – “Tấm khiên” bảo mật thông minh
Purview tự động phát hiện các dữ liệu nhạy cảm như:
💳 Số thẻ tín dụng
📧 Email
👤 Thông tin cá nhân (PII)
…để gắn nhãn bảo mật.
🔒 Không còn cảnh dữ liệu thô nhạy cảm “vô tình” đi lạc lên các báo cáo công khai của công ty nữa.

💡 Góc nhìn nhanh cho anh em Data:
Làm Data Engineering không chỉ có cày cuốc ETL/ELT, mà còn là quản trị sao cho hệ thống luôn minh bạch, dễ truy vết và an toàn.
Đầu tư cho Microsoft Purview có thể không giúp pipeline chạy nhanh hơn, nhưng chắc chắn giúp anh em Data Engineer và Business Users ngủ ngon hơn mỗi đêm!

06/07/2026

Fabric Warehouse: 3 DMV để biết “ngay lúc này” hệ thống đang làm gì 🔎

Khi có người báo “report chạy hoài không ra”, việc đầu tiên không phải đoán mò, mà là nhìn vào cái đang chạy real-time. Fabric Warehouse kế thừa 3 DMV quen thuộc từ SQL Server cho việc này:

🔎 Đi theo thứ tự drill-down: connection → session → request
1. sys.dm_exec_connections – Ai đang kết nối?
• Cho biết session id, địa chỉ client, giao thức, kiểu xác thực.
2. sys.dm_exec_sessions – Phiên nào đang hoạt động?
• Mỗi kết nối mở ra một hay nhiều session: user nào, trạng thái phiên, đang chạy hay đang chờ.
3. sys.dm_exec_requests – Request nào đang chạy và chạy bao lâu?
• View đắt giá nhất khi chữa cháy: status, total_elapsed_time, và câu lệnh đang thực thi.
⚡ Câu query bạn sẽ gõ nhiều nhất — tìm request đang chạy lâu nhất:
(ảnh đính kèm)

🔴 Bắt được “thủ phạm” đang treo, bạn có thể hủy phiên đó: KILL 'SID######xx'; (thay bằng session_id thật).

⚠️ Lưu ý: nhóm sys.dm_exec_* chỉ thấy cái đang active. Query xong là biến mất — muốn xem lịch sử phải sang Query Insights.

💡 Kết luận:
Khi cần phản ứng nhanh (“ngay bây giờ chuyện gì đang xảy ra”), connection → session → request là bộ ba để truy vết tức thì trong Fabric Warehouse.

04/07/2026

Lên Fabric Warehouse: bộ công cụ monitoring đã thay đổi thế nào?

Nếu bạn từng monitor Azure Synapse Dedicated Pool, chắc bạn quen mặt bộ sys.dm_pdw_exec_requests, sys.dm_pdw_request_steps, sys.dm_pdw_dms_workers — dùng để soi từng step của query và bắt data movement giữa 60 distributions.
Chuyển sang Microsoft Fabric Warehouse, bộ dm_pdw_* không còn nữa. Lý do: kiến trúc đã đổi — không còn DWU hay distribution để bạn tự tay chỉnh, engine tự lo việc phân tán. Vậy giờ monitor bằng gì?

🔹 Fabric Warehouse cho bạn 2 nhóm công cụ bằng T-SQL:
1. DMV “thời gian thực” – họ sys.dm_exec_*
• sys.dm_exec_connections, sys.dm_exec_sessions, sys.dm_exec_requests: xem ngay bây giờ ai đang kết nối, phiên nào đang chạy, query nào đang ngốn tài nguyên.
• Chỉ thấy cái đang active — query xong là biến mất.
2. Query Insights – schema queryinsights
• exec_requests_history, exec_sessions_history, long_running_queries, frequently_run_queries: phân tích lịch sử để biết query nào chậm kinh niên, query nào chạy nhiều nhất.
• Fabric tự sinh các view này trong mỗi Warehouse.
👉 Lười gõ T-SQL? Trong portal đã có tab Query activity / Monitor (xem trực tiếp, không cần code) và Capacity Metrics App để soi mức tiêu hao CU.

💡 Điểm mấu chốt:
Tư duy monitor đã đổi. Ở Synapse bạn lo “data movement giữa các node”. Ở Fabric mối quan tâm dịch sang: query này quét bao nhiêu data, ăn bao nhiêu CPU, và tiêu bao nhiêu CU của capacity.

02/07/2026

Tôi đã từng xóa nhầm bảng data production lúc 9h tối. 😅

Hôm đó deadline gấp, tôi mở Azure SQL Database để dọn dẹp mấy bảng test. Quen tay gõ DROP TABLE customers;, nhấn Enter… rồi lạnh sống lưng khi nhìn lên góc màn hình: tôi đang đứng ở môi trường PRODUCTION, không phải DEV.

Vài giây đó dài như cả thế kỷ. Tim đập thình thịch, tay run run. Nhưng cuối cùng mọi chuyện được cứu — và đây là những gì tôi rút ra:
✅ Backup là "phao cứu sinh", không phải thủ tục cho có.
Azure SQL có Point-in-time Restore giúp tôi quay về trạng thái 5 phút trước sự cố. Nếu hôm đó không bật, chắc tôi đã có một đêm trắng thật sự.
✅ Versioning cứu bạn nhanh hơn bạn tưởng.
Toàn bộ schema và script đều nằm trong Git, nên việc rebuild lại cấu trúc gần như tức thì. Code mà không version thì khôi phục bằng… trí nhớ.
✅ Phân quyền chặt = bớt một đêm mất ngủ.
Sau lần đó, tài khoản hằng ngày của tôi KHÔNG còn quyền DROP/TRUNCATE trên production. Muốn thao tác nguy hiểm? Phải dùng tài khoản riêng, có người duyệt.
✅ Tách môi trường rõ ràng (DEV / STAGING / PROD).
Mỗi môi trường một màu giao diện, một cảnh báo riêng. Nghe nhỏ nhặt, nhưng chính nó chặn 90% lỗi "nhầm tay".
✅ Lệnh nguy hiểm → luôn SELECT trước khi DELETE/DROP.
Một thói quen 5 giây, đổi lại sự an tâm rất lớn.
Bài học lớn nhất: Sai sót là điều khó tránh. Nhưng một hệ thống tốt sẽ biến "thảm họa" thành "một phút hú vía".

Đừng đợi mất data mới đi làm backup nhé. 🙏
Còn bạn, đã bao giờ "toát mồ hôi hột" với production chưa? Kể tôi nghe với! 👇

TC Data

28/07/2026

24/07/2026

22/07/2026

20/07/2026

17/07/2026

15/07/2026

09/07/2026

06/07/2026

04/07/2026

02/07/2026

Address

Website

Alerts

Shortcuts

Share

Category