GALAXY TECH
Chuyên gia Công nghệ
Thứ ba, 26/09/2017 | 00:00 GMT+7

3 Chiến lược giảm thiểu thời gian ngừng hoạt động

Giới thiệu

Khi các doanh nghiệp và các tổ chức khác ngày càng phụ thuộc vào các dịch vụ dựa trên internet, các nhà phát triển và sysadmins đang tập trung sự chú ý của họ vào việc tạo ra cơ sở hạ tầng tin cậy để giảm thiểu thời gian chết tốn kém.

Một trang web, API hoặc dịch vụ khác không khả dụng có thể có chi phí tiền tệ đáng kể do doanh số bán hàng bị mất. Ngoài ra, thời gian chết có thể dẫn đến:

  • Khách hàng và User không hài lòng: User mong đợi các dịch vụ ổn định. Việc gián đoạn có thể dẫn đến tăng yêu cầu hỗ trợ và mất niềm tin chung vào thương hiệu của bạn.
  • Năng suất bị mất: Nếu nhân viên của bạn phụ thuộc vào một dịch vụ để thực hiện công việc của họ, thời gian ngừng hoạt động đồng nghĩa với việc mất năng suất cho tổ chức của bạn. Ngoài ra, nếu nhân viên của bạn đang dành thời gian khởi động lại server và chống lại thời gian chết, họ không phát triển các tính năng và sản phẩm mới.
  • Nhân viên không hài lòng: Thông báo về thời gian ngừng hoạt động thường xuyên có thể dẫn đến tình trạng mệt mỏi khi cảnh báo và liên tục tranh giành để giải quyết vấn đề có thể gây tổn hại đến group của bạn và tinh thần của họ.

Lĩnh vực hiện đại đã liên kết lại để giải quyết những vấn đề này được gọi là Kỹ thuật độ tin cậy của trang web hoặc SRE. SRE được tạo ra tại Google bắt đầu từ năm 2003 và các chiến lược mà họ phát triển được tập hợp thành một cuốn sách có tiêu đề Kỹ thuật độ tin cậy của trang web . Đọc về lĩnh vực này là một cách tốt để khám phá các kỹ thuật và phương pháp hay nhất để giảm thiểu thời gian chết.

Trong bài viết này, ta sẽ thảo luận về ba lĩnh vực mà các cải tiến có thể dẫn đến ít thời gian ngừng hoạt động hơn cho tổ chức của bạn. Các lĩnh vực này là giám sát và cảnh báo , triển khai phần mềm và tính sẵn sàng cao .

Đây không phải là danh sách đầy đủ các chiến lược, nhưng nhằm chỉ cho bạn một số giải pháp phổ biến mà bạn nên xem xét khi cải thiện mức độ sẵn sàng production dịch vụ của bạn .

1. Giám sát và Cảnh báo

Theo dõi cơ sở hạ tầng của bạn một cách thích hợp sẽ cho phép bạn chủ động theo dõi các vấn đề sắp xảy ra, cảnh báo cho group của bạn về các vấn đề và dễ dàng điều tra nguyên nhân của các lần ngừng hoạt động trước đó. Giám sát liên quan đến việc tổng hợp và ghi lại các số liệu thống kê như việc sử dụng tài nguyên hệ thống và số liệu hiệu suất ứng dụng. Cảnh báo được xây dựng dựa trên bộ sưu tập chỉ số này bằng cách liên tục đánh giá các luật cảnh báo dựa trên các chỉ số hiện tại để xác định thời điểm cần thực hiện hành động.

Việc giám sát thường được thực hiện với một client trên mỗi server lưu trữ để thu thập các chỉ số và báo cáo lại server trung tâm. Các số liệu sau đó được lưu trữ trong database chuỗi thời gian (cơ sở dữ liệu chuyên lưu trữ và tìm kiếm dữ liệu số được đánh dấu thời gian) và có sẵn để vẽ đồ thị, tìm kiếm và cảnh báo. Một số ví dụ về phần mềm giám sát là:

  • Prometheus có thể lấy dữ liệu từ nhiều khách hàng chính thức và được cộng đồng hỗ trợ (được gọi là nhà xuất khẩu ). Nó có khả năng mở rộng cao, có cảnh báo tích hợp và có sẵn các thư viện client cho hầu hết các ngôn ngữ lập trình.
  • Graphite cung cấp một API phổ biến hiện nay được hỗ trợ bởi hàng chục ngôn ngữ lập trình và ứng dụng. Các chỉ số được đẩy từ các node đến cài đặt Graphite trung tâm, nơi chúng được lưu trữ và vẽ biểu đồ.

Việc đẩy các file log đến dịch vụ trung tâm và phân tích cú pháp chúng cho các chỉ số liên quan như ngoại lệ và tỷ lệ lỗi cũng rất phổ biến. Ngăn xếp elastic (Elasticsearch, Logstash, Kibana) và Graylog là những ví dụ về ngăn xếp phần mềm có thể hỗ trợ phân tích và phân tích file log .

Chỉ số nào cần theo dõi

Các chỉ số hữu ích nhất cần thu thập khi cố gắng tăng độ tin cậy và giảm thời gian chết là gì?

Hầu hết các khách hàng giám sát và nhà xuất khẩu sẽ có một bộ số liệu mặc định là điểm khởi đầu tốt, nhưng ứng dụng hoặc dịch vụ của bạn sẽ có những nhu cầu riêng mà bạn cần xem xét khi quyết định xuất các phép đo nào.Rất may, tài liệu SRE có một số hướng dẫn chung về những số liệu hữu ích nhất để theo dõi. Các chỉ số này được group lại thành Bốn tín hiệu vàng , được tóm tắt tại đây từ cuốn sách SRE :

  • Độ trễ: mất bao lâu để phản hồi một yêu cầu. Ví dụ: thời gian phản hồi của server cho một yêu cầu HTTP.
  • Lưu lượng: nhu cầu mà hệ thống của bạn đang gặp phải. Đây có thể là tốc độ yêu cầu cho web server , I / O mạng, đăng nhập mỗi giây hoặc giao dịch mỗi giây cho database .
  • Lỗi: tỷ lệ thất bại của các giao dịch hoặc yêu cầu. Lưu ý không phải mọi lỗi đều rõ ràng như lỗi HTTP 500. Ví dụ: policy của bạn có thể là khách hàng sẽ nhận được phản hồi trong 500 mili giây hoặc ít hơn. Bất kỳ phản hồi nào có độ trễ cao hơn sẽ hiển thị dưới dạng lỗi trong trường hợp này.
  • Độ bão hòa: mức độ "đầy đủ" của một dịch vụ. Điều này có thể đo dung lượng khả dụng trên ổ cứng, thông lượng mạng hoặc thậm chí là lượng CPU có sẵn trên một dịch vụ ràng buộc CPU.

Hình dung các chỉ số

Sau khi cài đặt hệ thống giám sát, bạn cần khám phá dữ liệu mà mình đang thu thập. Grafana là một gói phần mềm cung cấp khả năng khám phá rất linh hoạt các chỉ số thông qua biểu đồ và trang tổng quan. Hình ảnh trực quan có thể được tổng hợp từ nhiều nguồn dữ liệu backend , bao gồm Graphite, Prometheus và Elasticsearch.

Cài đặt cảnh báo

Ngoài việc trực quan hóa các số liệu của bạn , bạn cũng cần cài đặt một số cách để tự động cảnh báo cho group của bạn khi có vấn đề. Grafana có khả năng cảnh báo, Prometheus cũng vậy thông qua thành phần Alertmanager của nó. Các gói phần mềm khác cho phép bạn xác định các luật cảnh báo cho các số liệu bao gồm Nagios và Sensu .

Cách bạn cấu trúc hệ thống cảnh báo sẽ phụ thuộc rất nhiều vào tổ chức của bạn. Nếu bạn có nhiều group , cảnh báo có thể được chuyển trực tiếp đến group chịu trách nhiệm về dịch vụ hoạt động sai. Hoặc bạn có thể có một vòng quay cuộc gọi đã lên lịch để xử lý tất cả các cảnh báo trong một khoảng thời gian cụ thể. Cảnh báo có thể được gửi qua email, thông báo đẩy hoặc dịch vụ phân trang của bên thứ ba.

Điều chính cần nhớ là mục tiêu phải cảnh báo càng ít càng tốt và chỉ cho những sự kiện mà group của bạn có thể thực hiện hành động ngay lập tức để giải quyết vấn đề. Quá nhiều cảnh báo hoặc cảnh báo cho những tình huống không có thể khắc phục được có thể khiến cảnh báo mệt mỏi . Mệt mỏi này có thể dẫn đến nhân viên không hài lòng những người có thể bỏ lỡ hoặc bỏ qua cảnh báo rằng rất quan trọng và hữu dụng.

Sách SRE tóm tắt một số nguyên tắc cần ghi nhớ khi cài đặt cảnh báo :

  • Mỗi khi máy nhắn tin hoạt động, tôi sẽ có thể phản ứng với cảm giác khẩn trương. Tôi chỉ có thể phản ứng với cảm giác khẩn cấp vài lần trong ngày trước khi trở nên mệt mỏi.
  • Mọi trang đều có thể hành động được.
  • Mọi phản hồi trang phải yêu cầu thông minh. Nếu một trang chỉ đạt được phản hồi của rô bốt, nó không phải là một trang.
  • Các trang phải nói về một vấn đề mới hoặc một sự kiện chưa từng thấy trước đây.

Nếu cảnh báo của bạn không đáp ứng các tiêu chí này, tốt nhất có thể gửi nó đến hệ thống bán vé hoặc file log có mức độ ưu tiên thấp hơn hoặc xóa hoàn toàn cảnh báo.

Để biết thêm thông tin về cách cài đặt một số hệ thống giám sát và cảnh báo open-souce , vui lòng tham khảo các hướng dẫn liên quan bên dưới.

Hướng dẫn liên quan:

2. Cải thiện triển khai phần mềm

Một lĩnh vực khác có thể có tác động đến thời gian chết là chiến lược triển khai phần mềm của bạn. Nếu quy trình triển khai của bạn yêu cầu nhiều bước thủ công để hoàn thành hoặc quá phức tạp, thì môi trường production của bạn có thể tụt hậu đáng kể so với môi trường phát triển của bạn. Điều này có thể dẫn đến việc phát hành phần mềm rủi ro hơn, vì mỗi lần triển khai trở thành một tập hợp thay đổi lớn hơn nhiều với nhiều phức tạp tiềm ẩn hơn. Điều này lại dẫn đến lỗi, làm chậm tốc độ phát triển và có thể dẫn đến việc vô tình triển khai các dịch vụ đã xuống cấp hoặc không khả dụng.

Sẽ mất một khoảng thời gian báo trước và lập kế hoạch để hoàn thiện các triển khai của bạn, nhưng cuối cùng, việc đưa ra chiến lược cho phép bạn tự động hóa quy trình tích hợp mã, thử nghiệm và triển khai sẽ dẫn đến một môi trường production chặt chẽ hơn phù hợp với sự phát triển - với việc triển khai thường xuyên hơn và ít phức tạp hơn giữa các bản phát hành.

Các phương pháp hay nhất về CI / CD

Với sự đa dạng của công nghệ containers , phần mềm quản lý cấu hình, ngôn ngữ lập trình và hệ điều hành có sẵn ngày nay, các chi tiết cụ thể về cách tự động hóa việc triển khai của bạn nằm ngoài phạm vi của bất kỳ bài viết nào. Nói chung, một nơi tốt để tham khảo là đảm bảo bạn đang tuân theo các phương pháp hay nhất về phân phối tích hợp liên tục (CI) (CD) và kiểm tra phần mềm của bạn . Một số phương pháp hay nhất này bao gồm:

  • Duy trì một repository duy nhất: mọi người nên thường xuyên tích hợp mã vào cùng một repository , nơi chứa mọi thứ cần thiết (bao gồm các file kiểm tra và cấu hình) để xây dựng dự án trên một máy tương đối trống hoặc trong môi trường CI. Điều này đảm bảo mọi người đang làm việc trên một cơ sở mã giống nhau, việc tích hợp tương đối dễ dàng và mọi người đều có thể kiểm tra và xây dựng các thay đổi của bạn một cách dễ dàng.
  • Tự động kiểm tra và xây dựng: phần mềm hoặc dịch vụ CI của bạn có thể tự động chạy kiểm tra và xây dựng dự án của bạn.
  • Tự động triển khai: phần mềm CI của bạn phải có thể triển khai và kiểm tra một bản dựng trong môi trường thử nghiệm mô phỏng chặt chẽ môi trường production cuối cùng.

Những thực tiễn này mô tả một môi trường tích hợp và phân phối liên tục, nhưng chúng không giúp ta triển khai production được hết. Có thể là - được cung cấp đủ tin tưởng vào thử nghiệm tự động của bạn - bạn có thể thoải mái khi tự động hóa triển khai sang production . Hoặc bạn có thể chọn đặt đây là một tác vụ thủ công (hay đúng hơn là một tác vụ tự động yêu cầu sự đánh giá của con người để bắt đầu).

Dù bằng cách nào, bạn cần một cách để đẩy version mới vào production mà không gây ra thời gian chết cho user của bạn. Việc triển khai thường xuyên sẽ là một bất tiện lớn nếu chúng liên quan đến gián đoạn dịch vụ trong khi cơ sở hạ tầng đang được cập nhật.

Triển khai Blue-Green

Một cách cụ thể để thực hiện một bước thúc đẩy production cuối cùng một cách an toàn - với sự phân chia liền mạch giữa các version - được gọi là triển khai xanh lam-xanh lục .

Việc triển khai màu xanh lam-xanh lá cây bao gồm việc cài đặt hai môi trường production giống hệt nhau đằng sau một cơ chế có thể dễ dàng chuyển đổi lưu lượng giữa hai môi trường. Cơ chế này có thể là một địa chỉ IP nổi có thể được chuyển đổi nhanh chóng giữa một server màu xanh lam hoặc xanh lá cây hoặc một bộ cân bằng tải để chuyển đổi giữa toàn bộ các cụm của nhiều server .

Tại bất kỳ thời điểm nào, chỉ có một trong các môi trường - giả sử trong trường hợp này là màu xanh lam - đang hoạt động và nhận lưu lượng production . Quá trình phát hành version mới là:

  • Đẩy bản dựng sang môi trường không hoạt động (ví dụ như màu xanh lá cây).
  • Kiểm tra bản dựng trong môi trường production này.
  • Nếu tất cả các bài kiểm tra đều vượt qua, hãy cắt lưu lượng truy cập sang môi trường xanh bằng cách cập nhật cấu hình bộ cân bằng tải hoặc bằng cách gán IP nổi cho server xanh.

Kỹ thuật này có thêm lợi ích là cung cấp một cơ chế đơn giản để quay trở lại version trước nếu có bất kỳ điều gì xảy ra. Tiếp tục triển khai trước đó và ở chế độ chờ cho đến khi bạn thấy phù hợp với bản phát hành mới. Nếu cần khôi phục lại, hãy cập nhật lại bộ cân bằng tải hoặc IP nổi để hoàn nguyên về trạng thái trước đó.

, có nhiều cách để đạt được mục tiêu tự động hóa quy trình triển khai của bạn theo cách an toàn và có khả năng chịu lỗi. Ta chỉ nêu bật một khả năng ở đây. Các hướng dẫn liên quan bên dưới có thêm thông tin về phần mềm CI / CD open-souce và triển khai màu xanh lam.

Hướng dẫn liên quan:

3. Triển khai tính sẵn sàng cao

Một chiến lược cuối cùng để giảm thiểu thời gian chết là áp dụng khái niệm tính sẵn sàng cao cho cơ sở hạ tầng của bạn. Thuật ngữ tính sẵn sàng cao bao hàm một số nguyên tắc thiết kế các hệ thống dự phòng và có khả năng phục hồi. Các hệ thống này thường phải:

  • Loại bỏ các điểm lỗi duy nhất: điều này thường nghĩa là nhiều server dự phòng hoặc các dịch vụ dự phòng được tích hợp sẵn. Cũng đang được xem xét là khả năng trải rộng cơ sở hạ tầng giữa nhiều trung tâm dữ liệu ở nhiều khu vực. Mức độ bạn đi sâu trong việc loại bỏ những nút thắt này sẽ khác nhau tùy thuộc vào khả năng chịu đựng của bạn đối với chi phí và độ phức tạp cũng như nhu cầu của tổ chức và user của bạn. Chẳng hạn, không phải tất cả các dịch vụ đều cần bộ cân bằng tải dự phòng và chuyển đổi dự phòng tự động giữa các vùng.
  • Lưu lượng chuyển hướng liền mạch: để giảm thiểu thời gian chết, việc cắt lưu lượng giữa các server phải nhanh chóng, với sự gián đoạn dịch vụ tối thiểu.
  • Phát hiện tình trạng của hệ thống dự phòng: để thông báo quyết định về thời điểm định tuyến lại lưu lượng, hệ thống phải có khả năng xác định khi nào một dịch vụ bị lỗi.

Nâng cấp web server với bộ cân bằng tải

Một ví dụ về việc nâng cấp lên cơ sở hạ tầng khả dụng cao hơn sẽ là chuyển từ một web server duy nhất sang nhiều web server và bộ cân bằng tải. Bộ cân bằng tải sẽ thực hiện kiểm tra tình trạng thường xuyên trên các web server và sẽ định tuyến lưu lượng truy cập khỏi những server bị lỗi. Cơ sở hạ tầng này cũng có thể cho phép triển khai mã liền mạch hơn, như đã thảo luận trong phần trước.

Tăng khả năng phục hồi database

Một ví dụ khác về việc thêm khả năng phục hồi và dự phòng là sao chép database . Ví dụ, server database MySQL có nhiều cấu hình sao chép khác nhau.Nhân rộng group thú vị ở chỗ nó cho phép cả hoạt động đọc và ghi trên một cụm server dự phòng. Thay vì có tất cả dữ liệu trên một server duy nhất, dễ bị lỗi thời gian chết, bạn có thể sao chép giữa nhiều server . MySQL sẽ tự động phát hiện các server bị lỗi và định tuyến xung quanh vấn đề.

Các database mới hơn, chẳng hạn như CockroachDB đang được xây dựng từ đầu với các tính năng sao chép dự phòng này, cho phép truy cập database có tính khả dụng cao trên nhiều máy trong nhiều trung tâm dữ liệu.

Sử dụng IP nổi và server dự phòng nóng

Một ví dụ cuối cùng về kiến trúc có tính khả dụng cao là sử dụng các IP nổi để không lưu lượng truy cập đến một server dự phòng nóng . Nhiều nhà cung cấp cloud có địa chỉ IP đặc biệt có thể nhanh chóng được gán lại cho các server khác nhau hoặc bộ cân bằng tải bằng cách sử dụng API. Dự phòng nóng là một server dự phòng luôn sẵn sàng hoạt động, nhưng không nhận được lưu lượng truy cập nào cho đến khi server chính không kiểm tra được tình trạng. Tại thời điểm đó, IP nổi được gán lại cho dự phòng nóng và lưu lượng truy cập theo sau. Để thực hiện các kiểm tra tình trạng này và các lệnh gọi API IP nổi, bạn cần cài đặt và cấu hình một số phần mềm bổ sung, chẳng hạn như keepalived hoặc heartbeat .

Các hướng dẫn liên quan bên dưới nêu bật nhiều phần mềm và công cụ hơn được dùng để tăng khả năng phục hồi của cơ sở hạ tầng của bạn.

Hướng dẫn liên quan:

Kết luận

Trong bài viết này, ta đã xem xét ba lĩnh vực mà các cải tiến đối với quy trình hoặc cơ sở hạ tầng có thể dẫn đến thời gian ngừng hoạt động ít hơn, bán được nhiều hơn và user hạnh phúc hơn. Theo dõi các chỉ số, cải thiện triển khai và tăng tính khả dụng của cơ sở hạ tầng là những nơi tốt để bắt đầu điều tra những thay đổi mà bạn có thể triển khai để làm cho ứng dụng hoặc dịch vụ của bạn sẵn sàng production và linh hoạt hơn.

Tất nhiên, có nhiều điều hơn nữa về độ tin cậy ngoài ba điểm này. Để biết thêm thông tin, bạn có thể đi sâu hơn vào các hướng dẫn được đề xuất ở cuối mỗi phần và xem sách Kỹ thuật về độ tin cậy của trang web , được cung cấp miễn phí trực tuyến .

Tags:

Các tin liên quan