Ngay cả khi thảm họa vẫn luôn có thời gian để uống một tách trà
DRP (kế hoạch khắc phục thảm họa) là một thứ mà lý tưởng nhất là sẽ không bao giờ cần thiết. Nhưng nếu đột nhiên hải ly di cư trong mùa giao phối gặm nhấm sợi quang xương sống hoặc quản trị viên cấp dưới làm mất cơ sở sản xuất, bạn chắc chắn muốn chắc chắn rằng mình sẽ có kế hoạch sẵn để làm gì với tất cả sự ô nhục này.
Trong khi khách hàng hoảng loạn bắt đầu cắt điện thoại hỗ trợ kỹ thuật thì cấp dưới đang tìm kiếm xyanua, bạn khôn ngoan mở phong bì màu đỏ và bắt đầu sắp xếp mọi thứ vào trật tự.
Trong bài đăng này, tôi muốn chia sẻ các đề xuất về cách viết DRP và những gì nó nên chứa. Chúng ta cũng sẽ xem xét những điều sau đây:
- Hãy học cách suy nghĩ như một nhân vật phản diện.
- Hãy cùng xem lợi ích của một tách trà trong thời kỳ tận thế.
- Hãy suy nghĩ về cấu trúc DRP thuận tiện
- Hãy xem cách kiểm tra nó
Điều này có thể hữu ích cho những công ty nào?
Rất khó để vạch ra ranh giới khi bộ phận CNTT bắt đầu cần những thứ như vậy. Tôi muốn nói rằng bạn chắc chắn cần DRP nếu:
- Việc dừng máy chủ, ứng dụng hoặc mất một số cơ sở dữ liệu sẽ dẫn đến tổn thất đáng kể cho toàn bộ doanh nghiệp.
- Bạn có một bộ phận CNTT chính thức. Theo nghĩa của một bộ phận, dưới hình thức một đơn vị chính thức của công ty, có ngân sách riêng, chứ không chỉ có một số nhân viên mệt mỏi đang lắp đặt mạng, diệt virus và nạp lại máy in.
- Bạn có ngân sách thực tế để dự phòng ít nhất một phần trong trường hợp khẩn cấp.
Khi bộ phận CNTT đã cầu xin ít nhất một vài ổ cứng vào máy chủ cũ trong nhiều tháng để sao lưu, bạn khó có thể tổ chức chuyển toàn bộ dịch vụ bị lỗi để dự trữ dung lượng. Mặc dù ở đây tài liệu sẽ không thừa.
Tài liệu là quan trọng
Bắt đầu với tài liệu. Giả sử dịch vụ của bạn chạy trên tập lệnh Perl được quản trị viên viết cách đây ba thế hệ, nhưng không ai biết nó hoạt động như thế nào. Khoản nợ kỹ thuật tích lũy và việc thiếu tài liệu chắc chắn sẽ bắn vào bạn không chỉ ở đầu gối mà còn ở các chi khác, vấn đề là thời gian.
Khi bạn đã có mô tả tốt về các thành phần dịch vụ, hãy tra cứu số liệu thống kê về tai nạn. Họ gần như chắc chắn sẽ hoàn toàn điển hình. Ví dụ: đĩa của bạn thỉnh thoảng bị đầy, điều này khiến cho nút bị lỗi cho đến khi nó được dọn sạch theo cách thủ công. Hoặc dịch vụ khách hàng không khả dụng do ai đó lại quên gia hạn chứng chỉ và Let's Encrypt không thể hoặc không muốn định cấu hình.
Những suy nghĩ như kẻ phá hoại
Phần khó khăn nhất là dự đoán những tai nạn chưa từng xảy ra trước đây nhưng có khả năng làm hỏng hoàn toàn dịch vụ của bạn. Ở đây tôi và các đồng nghiệp thường đóng vai phản diện. Uống thật nhiều cà phê và thứ gì đó ngon rồi nhốt mình trong phòng họp. Chỉ cần đảm bảo rằng trong cùng các cuộc đàm phán, bạn sẽ thu hút được những kỹ sư đã tự phát triển dịch vụ mục tiêu hoặc thường xuyên làm việc với dịch vụ đó. Sau đó, trên bảng hoặc trên giấy, bạn bắt đầu vẽ ra tất cả những điều khủng khiếp có thể xảy ra với dịch vụ của mình. Không cần thiết phải đi sâu vào chi tiết đến gặp một cô lao công cụ thể và rút dây cáp, chỉ cần xem xét kịch bản “Vi phạm tính toàn vẹn của mạng cục bộ”.
Thông thường, hầu hết các tình huống khẩn cấp điển hình đều thuộc các loại sau:
- Lỗi mạng
- Lỗi dịch vụ hệ điều hành
- Lỗi ứng dụng
- Lỗi sắt
- Lỗi ảo hóa
Chỉ cần xem qua từng loại và xem những gì áp dụng cho dịch vụ của bạn. Ví dụ: daemon Nginx có thể giảm và không tăng - điều này có nghĩa là hệ điều hành bị lỗi. Một tình huống hiếm gặp khiến ứng dụng web của bạn bị lỗi đó là lỗi phần mềm. Trong khi vượt qua giai đoạn này, điều quan trọng là phải tìm ra chẩn đoán vấn đề. Ví dụ: làm cách nào để phân biệt giao diện bị đóng băng trên ảo hóa với ổ cis bị hỏng và sự cố mạng. Điều quan trọng là phải nhanh chóng tìm ra những người chịu trách nhiệm và bắt đầu kéo đuôi họ cho đến khi tai nạn được giải quyết.
Sau khi các vấn đề điển hình được viết ra, chúng tôi rót thêm cà phê và bắt đầu xem xét các tình huống kỳ lạ nhất khi một số thông số bắt đầu vượt xa định mức. Ví dụ:
- Điều gì xảy ra nếu thời gian trên nút đang hoạt động lùi lại một phút so với các nút khác trong cụm?
- Nếu thời gian trôi qua, nếu 10 năm nữa thì sao?
- Điều gì xảy ra nếu một nút cụm đột nhiên mất mạng trong quá trình đồng bộ hóa?
- Điều gì sẽ xảy ra nếu hai nút không chia sẻ quyền lãnh đạo do sự cô lập tạm thời của nhau trên mạng?
Ở giai đoạn này, cách tiếp cận ngược lại rất hữu ích. Bạn bắt thành viên cứng đầu nhất trong nhóm có trí tưởng tượng bệnh hoạn và giao cho anh ta nhiệm vụ tổ chức một vụ phá hoại trong thời gian ngắn nhất để làm sụp đổ dịch vụ. Nếu khó chẩn đoán thì càng tốt. Bạn sẽ không tin được những ý tưởng kỳ lạ và thú vị mà các kỹ sư nghĩ ra nếu bạn cho họ ý tưởng để phá vỡ thứ gì đó. Và nếu bạn hứa với họ một băng ghế thử nghiệm cho việc này thì điều đó hoàn toàn ổn.
DRP này của bạn là gì?!
Vậy là bạn đã xác định được mô hình mối đe dọa của mình. Họ cũng tính đến việc cư dân địa phương cắt cáp quang để tìm kiếm đồng và radar quân sự thả đường dây chuyển tiếp vô tuyến vào lúc 16:46 thứ Sáu. Bây giờ chúng ta cần hiểu phải làm gì với tất cả những điều này.
Nhiệm vụ của bạn là viết những phong bì màu đỏ sẽ được mở trong trường hợp khẩn cấp. Ngay lập tức mong đợi rằng khi (không phải nếu!) Mọi thứ kết thúc, chỉ có thực tập sinh thiếu kinh nghiệm nhất sẽ ở gần đó, người sẽ có đôi tay run rẩy dữ dội vì nỗi kinh hoàng về những gì đang xảy ra. Xem cách thực hiện các dấu hiệu khẩn cấp tại các cơ sở y tế. Ví dụ, phải làm gì trong trường hợp sốc phản vệ. Các nhân viên y tế thuộc lòng tất cả các quy trình, nhưng khi một người ở gần đó bắt đầu chết, mọi người thường bất lực trước mọi thứ trong tầm mắt. Để làm điều này, có những hướng dẫn rõ ràng trên tường với các mục như “mở gói như vậy và như vậy” và “tiêm thật nhiều đơn vị thuốc vào tĩnh mạch”.
Thật khó để suy nghĩ trong trường hợp khẩn cấp! Cần có những hướng dẫn đơn giản để phân tích tủy sống.
Một DRP tốt bao gồm một số khối đơn giản:
- Ai sẽ thông báo về sự khởi đầu của một vụ tai nạn. Điều này rất quan trọng để song song hóa quá trình loại bỏ càng nhiều càng tốt.
- Cách chẩn đoán chính xác - thực hiện theo dõi, tìm tên dịch vụ trạng thái systemctl, v.v.
- Bạn có thể dành bao nhiêu thời gian cho mỗi giai đoạn? Nếu bạn không có thời gian để khắc phục thủ công trong thời gian SLA, máy ảo sẽ bị tắt và khôi phục từ bản sao lưu ngày hôm qua.
- Làm thế nào để đảm bảo sự cố đã kết thúc.
Hãy nhớ rằng DRP bắt đầu khi dịch vụ bị lỗi hoàn toàn và kết thúc khi dịch vụ được khôi phục, ngay cả khi hiệu quả bị giảm. Việc mất đặt chỗ sẽ không kích hoạt DRP. Bạn cũng có thể viết một tách trà vào DRP. Nghiêm túc. Theo thống kê, nhiều vụ tai nạn chuyển từ khó chịu sang thảm khốc do nhân viên hoảng loạn vội vàng sửa chữa thứ gì đó, đồng thời giết chết nút sống duy nhất có dữ liệu hoặc cuối cùng là kết liễu cụm. Theo quy định, 5 phút với một tách trà sẽ giúp bạn có chút thời gian để bình tĩnh và phân tích những gì đang xảy ra.
Đừng nhầm lẫn giữa DRP và hộ chiếu hệ thống! Đừng làm nó quá tải với những dữ liệu không cần thiết. Chỉ cần giúp bạn có thể sử dụng các siêu liên kết một cách nhanh chóng và thuận tiện để đi đến phần tài liệu mong muốn và đọc ở định dạng mở rộng về các phần cần thiết của kiến trúc dịch vụ. Và trong bản thân DRP chỉ có hướng dẫn trực tiếp về vị trí và cách kết nối bằng các lệnh cụ thể để sao chép-dán.
Cách kiểm tra chính xác
Đảm bảo rằng bất kỳ nhân viên có trách nhiệm nào cũng có thể hoàn thành tất cả các mục. Vào thời điểm quan trọng nhất, có thể kỹ sư không có quyền truy cập vào hệ thống được yêu cầu, không có mật khẩu cho tài khoản được yêu cầu hoặc anh ta không biết “Kết nối với bảng điều khiển quản lý dịch vụ thông qua proxy tại trụ sở chính” có nghĩa là Mỗi điểm nên cực kỳ đơn giản.
Sai — “Vào ảo hóa và khởi động lại nút chết”
Chính xác - “Kết nối qua giao diện web tới virt.example.com, tại phần node khởi động lại node gây lỗi.”
Tránh sự mơ hồ. Hãy nhớ đến thực tập sinh sợ hãi.
Hãy chắc chắn kiểm tra DRP. Đây không chỉ là một kế hoạch để phô trương - nó là thứ sẽ cho phép bạn và khách hàng của bạn nhanh chóng thoát khỏi một tình huống nguy kịch. Tốt nhất nên làm điều này nhiều lần:
- Một chuyên gia và một số học viên làm việc trên một băng ghế thử nghiệm mô phỏng một dịch vụ thực tế nhiều nhất có thể. Chuyên gia phá vỡ dịch vụ theo nhiều cách khác nhau và cho phép học viên khôi phục dịch vụ theo DRP. Tất cả các vấn đề, tài liệu mơ hồ và sai sót đều được ghi lại. Sau khi học viên được đào tạo, DRP được mở rộng và đơn giản hóa ở những lĩnh vực chưa rõ ràng.
- Thử nghiệm trên một dịch vụ thực tế. Trên thực tế, bạn không bao giờ có thể tạo ra một bản sao hoàn hảo của một dịch vụ thực sự. Do đó, một vài lần trong năm, cần phải thường xuyên tắt một số máy chủ, cắt đứt kết nối và gây ra các thảm họa khác khỏi danh sách các mối đe dọa để đánh giá quy trình khôi phục. Sự cố được lên kế hoạch trong 10 phút vào lúc nửa đêm sẽ tốt hơn sự cố đột ngột trong vài giờ khi tải cao điểm và mất dữ liệu.
- Khắc phục sự cố thực sự. Vâng, đây cũng là một phần của thử nghiệm. Nếu xảy ra tai nạn không nằm trong danh sách nguy cơ thì cần bổ sung, hoàn thiện DRP dựa trên kết quả điều tra.
Những điểm chính
- Nếu chuyện tồi tệ có thể xảy ra, nó không chỉ xảy ra mà còn xảy ra trong tình huống thảm khốc nhất có thể.
- Đảm bảo bạn có nguồn lực để chuyển tải khẩn cấp.
- Hãy đảm bảo rằng bạn có bản sao lưu, chúng được tạo tự động và thường xuyên kiểm tra tính nhất quán.
- Hãy suy nghĩ về các tình huống đe dọa điển hình.
- Tạo cơ hội cho các kỹ sư đưa ra các phương án phi tiêu chuẩn để cung cấp dịch vụ.
- DRP phải là một hướng dẫn đơn giản và thẳng thắn. Tất cả các chẩn đoán phức tạp chỉ được thực hiện sau khi dịch vụ của khách hàng được khôi phục. Ngay cả khi ở công suất dự trữ.
- Cung cấp số điện thoại và địa chỉ liên hệ chính trong DRP.
- Kiểm tra sự hiểu biết của nhân viên về DRP thường xuyên.
- Sắp xếp các tai nạn theo kế hoạch tại nơi sản xuất. Khán đài không thể thay thế tất cả mọi thứ.
Nguồn: www.habr.com