Lâu rồi không viết bài mới vì nhiều lý do như sức khỏe, công việc, nhiều mối quan tâm khác, … nhưng thật ra lý do lớn nhất vẫn là lười… Nhìn chung, có những thứ bản thân biết là cần thiết nhưng không hiểu sao cứ luôn tự trì hoãn theo cách này hay cách khác. Chắc nhiều bạn cũng giống mình (hy vọng vậy …).
Dạo này gặp áp lực phải viết lại, nên thôi chọn một chủ đề nào đó dễ viết mà không cần phải suy nghĩ quá nhiều, đó là kể lại công việc hàng ngày của mình.
Hiện giờ mình đang làm việc ở một công ty công nghệ với quy mô trên 1000 nhân sự dưới vai trò Engineer Manager. Mình đang phụ trách một team nhỏ có khoảng 15-16 người. Team của mình chịu trách nhiệm vận hành và phát triển cho một platform nội bộ bên trong công ty.
Thứ hai – ngày của planning
Sáng đầu tuần khởi động bằng hai cuộc họp sprint planning cho hai team đang phụ trách. Thường thứ hai sẽ được dùng cho sprint planning hoặc backlog grooming, xen kẽ mỗi tuần. Tuỳ vào lượng công việc mà có thể mình sẽ bỏ qua cuộc họp này mà chỉ theo dõi tình trạng backlog sau khi mọi người trong team đã họp xong.
Ở team mình, một sprint sẽ kéo dài hai tuần. Đầu sprint mọi người sẽ cùng duyệt qua backlog để chọn ra các task quan trọng cần phải hoàn thành trong sprint này. Sau đó mọi người cũng sẽ duyệt qua các project quan trọng và điều chỉnh lịch release dự kiến nếu cần thiết. Thông thường, backlog khá dài nên việc review các task và độ ưu tiên sẽ được làm trước trong các buổi backlog grooming của tuần trước đó để khi làm sprint planning thì sẽ không tốn thời gian review độ ưu tiên lại.
Chiều thứ hai thường sẽ có cuộc họp giao ban ngắn giữa oncall tuần trước và oncall tuần này. Ở công ty mình, tại một thời điểm sẽ luôn có người phụ trách trực cho một service hoặc một platform, người này sẽ được gọi là oncall. Tuỳ team mà ca trực oncall theo ngày hoặc theo tuần. Nhiệm vụ của oncall sẽ là theo dõi tình hình hệ thống, phản ứng khi có các cảnh báo sự cố hoặc vấn đề xảy ra, trả lời các câu hỏi của team khác liên quan đến các phần hệ thống của team mình. Trong buổi họp giao ban này, người phụ trách oncall tuần trước sẽ điểm qua những vấn đề phát sinh của tuần rồi và các điều cần lưu ý tiếp.
Trong chiều thứ hai này team mình có một buổi họp đột xuất để review một Post-mortem được viết bởi một bạn trong team, trình bày về nguyên nhân dẫn đến sự cố service bị nghẽn trong 2 ngày liên tục, mỗi lần nghẽn diễn ra trong 5 phút dẫn đến một loạt các service liên quan cũng bị nghẽn theo. Mọi người sẽ cùng review Post-mortem của bạn phụ trách và đưa ra góp ý, phản biện cũng như đặt các câu hỏi để làm rõ hơn về nguyên nhân sự cố.
Sự cố này thú vị vì sau khi điều tra cụ thể thì phát hiện ra mặt dù dấu hiệu ban đầu của việc bị nghẽn trong 2 ngày là giống nhau, nhưng nguyên nhân sâu xa gây ra lại hoàn toàn khác nhau. Ở ngày đầu tiên, service bị nghẽn vì một node trong cụm server không phục vụ được traffic cho các service khác dẫn đến mất cân bằng tải. Lý do là trong quá trình node này khởi động thì quá trình đăng ký node này vào danh mục service discovery bị lỗi, dẫn đến cụm server có 3 servers nhưng chỉ có 2 servers phục vụ được traffic thông qua service discovery. Điều này dẫn đến thuật toán auto-scaling của cụm server vốn dựa vào CPU trung bình không hoạt động đúng.
Ở ngày thứ hai, service bị nghẽn cũng vì một node trong cụm không phục vụ được traffic cho các service khác thông qua ELB nhưng do quá trình khởi tạo và đánh nhãn bị lỗi nên không bị thay thế kịp lúc. Quá trình này cũng dẫn đến mất cân bằng tải.
Thời gian còn lại của buổi chiều có thể xen kẽ các session 1:1 ngắn với các thành viên đang quản lý trực tiếp, gián tiếp hoặc đang mentor.
Thứ ba – ngày của Operational Excellence
Sáng thứ ba thường sẽ bắt đầu bằng họp stand-up online với team nhỏ đang trực tiếp phụ trách. Trong buổi stand up các thành viên sẽ mở tasks board ra, sau đó từng thành viên sẽ lần lượt điểm qua các việc đã làm ngày hôm trước cũng như nêu ra các vấn đề cần xử lý. Nếu có vấn đề cần thảo luận thì các thành viên có thể tự hẹn để thảo luận riêng sau đó. Trong hoạt động này thì với vai trò EM, bản thân chỉ tham gia để cập nhật thông tin là chủ yếu, hoặc thỉnh thoảng có thể đưa ra góp ý về hướng xử lý một ticket là thoả đáng hay chưa.
Phần còn lại của buổi sáng sẽ là họp Operational Excellent của toàn công ty. Trong buổi họp này, các team phụ trách về vận hàng sẽ điểm qua nhiều vấn đề như tình hình cost, các incidents, các vấn đề về security, các vấn đề về độ ổn định chung của toàn hệ thống theo các nhóm service khác nhau. Ngoài ra, các team nào có sự cố sẽ trình bày Post Mortem của team mình.
Nói thêm một tí về Post-Mortem (PM), cấu trúc thường có của một PM thường bao gồm:
- Giới thiệu tổng quan về sự cố
- Timestamp các sự kiện diễn ra trước, trong và sau khi sự cố
- Phân tích sâu về nguyên nhân gốc rễ dẫn đến sự cố
- Các hành động đã làm để phục hồi hệ thống cũng như giảm thiểu thiệt hại (mitigate)
- Bài học kinh nghiệm cần rút ra.
Đối với một tổ chức lớn vận hành nhiều service phức tạp thì các PM là một hoạt động rất quan trọng vì nó sẽ giúp chúng ta rút kinh nghiệm mỗi khi có sự cố xảy ra. Một PM tốt cần phân tích sâu và đến gốc rễ vấn đề (Root-cause) để từ đó có thể rút ra bài học cho các service khác có thể áp dụng. Quá trình phân tích cũng có thể áp dụng nhiều kỹ thuật nhưng phổ biến nhất là 5-whys: đặt liên tục 5+ câu hỏi tại sao cho đến khi có thể chạm đến gốc rễ.
Ví dụ về quá trình đặt câu hỏi 5-whys được đơn giản hoá để có thể dễ hình dung:
- Tại sao lại service A lại có gặp lỗi 500 liên tục trong khung thời gian 15 phút từ thời điểm 11:00am đến 11:15am? → Tại vì service A gọi đến service B, service B trả về kết quả với độ trễ p99=800ms trong khi yêu cầu từ service A là 150ms.
- Tại sao service B lại trả về kết quả với độ trễ p99=800ms trong khung thời gian đó? → Tại vì database service B đang dùng trả về kết quả cho endpoint XX với độ trễ p99=700ms, cao hơn thường lệ.
- Tại sao database service B đang dùng lại trả về kết quả có độ trễ cao p99=700ms và cao hơn thường lệ? → Tại vì một partition của database đang dùng bị overload dẫn đến các request đến partition này có độ trễ cao hơn.
- Tại sao partition lại bị overload? → Tại vì có một lượng request tăng đột biến đến từ service C cũng gọi qua service B, trong lượng request này có kèm một số lệnh update đến từ partition tương ứng dẫn đến overload partition này.
- Tại sao lại có một lượng request tăng đột biến đến từ service C? → Tại vì redis cluster của service C bị down dẫn đến một lượng lớn request vốn nên được cache bởi service C bị đẩy sang service B.
Trong thực tế, việc đặt câu hỏi có thể nhiều hơn hoặc ít hơn. Nhưng nhìn chung khi phân tích, đặt câu hỏi đúng thì sẽ dẫn đến các bài học kinh nghiệm phù hợp để từ đó ngăn chặn các vấn đề phát sinh trong tương lai.
Kết thúc buổi sáng thứ ba, buổi chiều thường sẽ bắt đầu bằng buổi họp Operational Excellent của platform đang phụ trách. Trong đó, các thành viên sẽ review các thông số vận hành như SLI, SLO, các vấn đề mới phát sinh cần đào sâu, … Nếu chỉ số nào không đạt SLO thì sẽ cần điều tra nguyên nhân.
Tiếp đến sẽ là họp dành cho leader của platform đang phụ trách trong đó sẽ điểm qua các chủ đề tổng quan của platform như các use-case mới cần xử lý, thông tin từ các platform liên quan, chốt OKR, thảo luận milestone tiếp theo của các dự án đang triển khai, …
Phần còn lại của buổi chiều là xen kẽ 1:1 với leader hoặc coordinator cùng team, team khác để cập nhật tình hình lẫn nhau cũng như thảo luận về các dự án đang phụ trách của nhau. Đối với bản thân thì các buổi 1:1 là một hoạt động không thể thiếu đặc biệt là đối với các team liên quan để có thể tập trung thảo luận các chủ đề tổng quan về problem space của từng team, hoặc các vấn đề mang tính chất dài hạn hơn (3-6 tháng) thay vì các hoạt động hàng ngày vốn đã có quy trình tương ứng để xử lý.
(còn tiếp)
Con Mọt Sách 