Xây Dựng Tài Liệu Vận Hành (Runbook)
- Tôi phải làm gì khi Server down lúc nửa đêm ?
- Tôi phải làm gì khi dịch vụ thanh toán trừ nhầm tiền khách hàng ?
- Tôi phải làm gì khi lỡ tay xóa nhầm Database ?
- Tôi phải làm gì khi Không Biết NÊN Làm Gì? => HÃY ĐỌC RUNBOOK
05 tháng sau khi đưa Post Mortem vào thành công rực rỡ, các sự cố đã gặp đều dạy thêm được rất nhiều kinh nghiệm và năng lực mới cho team, chúng tôi tiếp tục quá trình xây dựng nhóm trực vận hành 24/7 với đầy thách thức mới, nhận thấy dù team có rất nhiều công cụ Infrastructure Management, Service Orchestration, Monitoring, Alerting, Incident Management nhưng nhân sự trực vận hành vẫn gặp vô vàn khó khăn khi bị dựng dậy lúc nửa đêm để hỗ trợ sự cố.
Một Phần Lý Do
Mục tiêu chính của team Development và team Operation dù cùng là mang lại giá trị cho khách hàng nhưng lại được định nghĩa theo các giá trị khác nhau:
- Development: Làm sao phát triển sản phẩm nhanh, đúng yêu cầu, chất lượng tốt … (Cần thay đổi liên tục)
- Operation: Làm sao vận hành sản phẩm ổn định, hiệu năng cao, bảo mật cao, … (Cần thay đổi chậm hơn, có kiểm soát, tuân thủ quy trình)
Chúng tôi quyết định làm mọi việc tốt hơn để hai team đồng bộ tầm nhìn, mục tiêu, tri thức chung chứ không chỉ làm việc qua hệ thống Issue và Release Request và Incident Response thuần tùy.
Và Runbook Đã Giúp Chúng Tôi
Về phía Development team
- Tạo lập phương pháp phối hợp hiệu quả với team Operation.
- Hỗ trợ hệ thống tài liệu thiết kế, vận hành đảm bảo luôn được update cùng các metric đo lường chất lượng từng dịch vụ.
- Tham gia sâu hơn vào các mà hệ thống vận hành trong môi trường Production và cùng đưa ra các giải pháp dài hạn cùng Operation, QA.
Về phía Operation team
- Tạo lập phương pháp phối hợp hiệu quả với team Development.
- Dễ dàng chấp nhận nhiều thay đổi hơn mà không gia tăng rủi ro.
- Phản ứng nhanh hơn khi sự cố xảy ra.
- Xây dựng tầm nhìn và quy hoạch dài hạn cho hệ thống.
Vậy Runbook Là Gì?
Runbook là tài liệu vận hành mô tả cách hệ thống đang được triển khai trên Production, vì mỗi hệ thống là duy nhất nên Runbook một tài liệu có-một-không-hai, không cái nào giống cái nào, RunBook cần dễ hiểu, nhất quán, mô tả chi tiết và chính xác nhiều khía cạnh của hệ thống/dịch vụ.
Các Thành Phần Của Một Runbook
- Overview: Mô tả chung đây là hệ thống gì, ý nghĩa của nó là gì, nó có quan trọng không, mức độ ưu tiên là bao nhiêu, ai là người cần liên hệ khi nó gặp sự cố.
- Architecture / Service Map / System & Network & Application Layers: Mô tả chi tiết thiết kế kĩ thuật của hệ thống.
- Common Tasks: Các nhiệm vụ cơ bản thường gặp và cách thực hiện theo từng bước. Ví dụ tăng RAM, thêm cấu hình, …
- Backup / Disaster Recovery Plans: Các phương pháp backup đang thực hiện và cách khắc phục khi có sự cố xảy ra, có thể các hướng dẫn chi tiết từng bước với từng loại sự cố. Ví dụ khi nhận được thông báo về dịch vụ thanh toán bị down thì cần check các dịch vụ chi tiết nào thông qua graph nào trên hệ thống Monitoring, nếu đúng là down thì cần kiểm tra log các dịch vụ nào trên hệ thống Log Centrelize, nếu thấy một dịch vụ down đơn giản do OutOfMemmory thì có thể khởi động lại bằng cách nào, ….
- Security Requirement: Các yêu cầu cần tuân thủ khi truy cập, tương tác với hệ thống.
- Service Level Agreement: Chất lượng dịch vụ đã cam kết và cần đảm bảo với phía khách hàng, ví dụ như Up time, Response time, ….
Để Runbook Có Giá Trị
- Các team cùng phải hiểu ý nghĩa và sự quan trọng của tài liệu.
- Các team đều cùng đóng góp xây dựng tài liệu.
- Mọi thay đổi, sự cố trong hệ thống đều phải được cập nhật vào Runbook thông qua Policy vận hành chặt chẽ.
- Mỗi khi cảm thấy Runbook vô giá trị, hãy quay lại cập nhật nó!
References:
- Gitlab Runbook: https://gitlab.com/gitlab-com/runbooks
- Run Book/Operations Manual: https://gist.github.com/voxxit/47e54a877bb56a8c8e3fd3492740aad2
- OpsDoc (Cực Hay): http://opsreportcard.com/section/11
