Incident đến lúc 23 giờ đêm giờ Sài Gòn, tag “dringend” (khẩn cấp). Tôi bật máy, fix xong 23 giờ 30, deploy lên staging, gõ một đoạn giải thích dài như sớ, rồi đi ngủ với cảm giác mình là hero.
Người đầu tiên mở incident ticket đó ra là… 14 giờ chiều hôm sau, giờ Sài Gòn. Anh PO bên Đức vừa uống xong ly cà phê đầu ngày.
Mấy năm làm engineer cho khách Đức từ Sài Gòn, tôi trải nghiệm mấy chuyện kiểu đó khá nhiều lần.
Lệch 5 tiếng, và Daylight Saving Time
Mùa hè Đức chạy CEST (UTC+2), Sài Gòn UTC+7 quanh năm vì Việt Nam không có giờ mùa hè. Lệch 5 tiếng. Ngày 25 tháng 10 năm nay họ lùi kim về CET (UTC+1), thành lệch 6 tiếng, và cái lịch họp recurring 14 giờ của tôi tự động nhảy sang 15 giờ mà chẳng ai báo.
Cửa sổ overlap thực tế: 14 giờ đến 18 giờ Sài Gòn mùa hè, 15 giờ đến 19 giờ mùa đông. Bốn tiếng. Năm đầu tôi nhét vào đó daily standup, refinement, retro, sync với team QA… rồi than là cả ngày không code được dòng nào.
Giờ tôi xem 4 tiếng đó như ngân sách. Chỉ chi cho thứ cần hai người cùng lúc: quyết định architecture, pairing để gỡ một bug lạ, demo, pair code review. Standup xin chuyển thành 5 dòng viết trong Slack. Code thì làm buổi sáng, khi cả nước Đức đang ngủ và Slack im như tờ.
Cái giá phải trả: review PR mất đúng một ngày. Tôi push lúc 11 giờ sáng, reviewer thấy lúc 14 giờ, hỏi một câu, tôi trả lời… sáng hôm sau họ mới đọc. Một PR to là ba ngày ping-pong. Nên PR phải nhỏ, và description phải viết như bàn giao ca cho người không thể hỏi lại mình.
Ở Đức, “quick fix” không tồn tại… và tôi đã học cách thích điều đó
Enterprise Đức có văn hoá Freigabe: mọi thứ lên production phải có người thứ hai ký. Bốn con mắt, một release window định sẵn. Hotfix cũng phải qua đó, chỉ là hàng đợi ngắn hơn.
Tháng đầu tôi muốn bùng cháy! Một dòng config sai trong payment plugin, tôi biết sửa trong 2 phút, mà phải viết ticket, đợi approve, đợi window. Ở startup cũ tôi ssh vào server sửa còn nhanh hơn.
Rồi tôi nhớ lại: cái “2 phút” đó của tôi rơi vào 23 giờ đêm, và trên toàn nước Đức lúc ấy không có ai tỉnh để rollback nếu tôi sai.
Quy trình chậm là cách họ bù cho việc thằng dev ngồi cách đó 9.000 km. Nó đổi tốc độ lấy bán kính nổ. Với một shop mà mỗi giờ checkout chết đo được bằng tiền thật, tôi thấy đó là một deal ổn.
Viết nhiều hơn nói: cái ADR 20 dòng cứu tôi ba, bốn lần
Câu hỏi hay đến lúc 17 giờ chiều Đức, tức 22 giờ Sài Gòn: “Sao lúc migrate lại chọn cách A mà không phải B?”. Nếu câu trả lời chỉ nằm trong đầu tôi, họ đợi tới trưa mai. Nếu nó nằm trong một trang Confluence 20 dòng ghi lúc quyết định, họ tự đọc rồi đi về.
Tôi ghi mỗi quyết định kỹ thuật đáng kể bằng đúng bốn mục: bối cảnh, phương án đã cân nhắc, chọn gì, và cái gì sẽ đau nếu chọn sai. Không template hoa mỹ. Cái ADR về việc giữ payment handler cũ chạy song song trong lúc migrate lên Shopware 6.7 đã được lôi ra ba lần, hai lần bởi người tôi chưa từng gặp.
Người Đức thích tài liệu là một stereotype có phần đúng. Nhưng tôi viết vì một lý do ích kỷ hơn: tôi ngủ khi họ làm việc, và văn bản là phiên bản duy nhất của tôi thức 24 giờ.
Vậy là sướng hay khổ?
Tôi nghĩ mãi…
Sướng nha 🙂 Buổi sáng yên tĩnh để code, chiều họp, tối được nghỉ thật vì không ai online để ping. Với một thằng dev 13 năm nghề đã chán cảnh bị kéo vào meeting lúc 9 giờ sáng, đây là setup dễ chịu nhất tôi từng có.
Có thể nó sẽ không hợp với người cần feedback trong 10 phút, hoặc người chưa quen tự quyết một mình rồi chịu trách nhiệm sáng hôm sau. Lệch giờ phóng đại mọi thói quen xấu về giao tiếp lên gấp đôi.
Bạn nào đang làm remote cho khách châu Âu, comment kể tôi nghe cái trải nghiệm bạn là gì? Thấy sướng hay thấy khổ?
Nếu nhiều người hỏi, bài sau tôi viết về chuyện setup tooling để pass được security review của khách Đức… cái này còn dài hơn.
Peace!
Ảnh: Luis Cortes trên Unsplash (Unsplash License), https://unsplash.com/photos/five-assorted-country-wall-clocks-QrPDA15pRkM
