Kế Hoạch DevOps - SLA Và Các Yêu Cầu Phi Chức Năng

DevOps Articles

Giới thiệu SLA trong DevOps

Bài viết này mô tả cách xác định SLA trong cách tiếp cận Kế hoạch DevOps.

Định nghĩa cho DevOps Plan

SLA

Thỏa thuận mức dịch vụ (SLA) là thỏa thuận giữa nhà cung cấp dịch vụ CNTT và khách hàng. Nội dung của SLA là về các chỉ tiêu chất lượng được chỉ định cho các sản phẩm, quy trình và dịch vụ. Ví dụ về định mức SLA cho một ứng dụng là: tính khả dụng là 99,9% với tối đa 3 sự cố mỗi năm và tối đa 3 giờ ngừng hoạt động. Trong bài viết này, nghĩa của thuật ngữ dịch vụ bao gồm sản phẩm. Tất cả đều nằm trong quan điểm của Kế hoạch DevOps.

Các khái niệm cho Kế hoạch DevOps - SLA

Một khái niệm quan trọng cho SLAs là các tiêu chuẩn dịch vụ phải được lấy từ các mục tiêu của các quy trình nghiệp vụ, xem Hình 1.

Căn chỉnh doanh nghiệp
Hình 1, Liên kết kinh doanh

Các quy trình nghiệp vụ (3) sử dụng các sản phẩm và dịch vụ (5). Các chỉ tiêu SLA (6) làm cho CSF ​​(4) có thể đo được bằng cách sử dụng KPI (4).

Điều quan trọng là nhận ra rằng các CSF (4) là những biện pháp đối phó với những rủi ro mà các mục tiêu kinh doanh (1) không có. Một phần rủi ro kinh doanh có thể được giảm thiểu bằng cách thực hiện các sản phẩm và dịch vụ kỹ thuật (16) và trong các quy trình quản lý dịch vụ (14).

Trên thực tế, SLA là một thỏa thuận giảm thiểu rủi ro kinh doanh của khách hàng.

Các phương pháp hay nhất - kế hoạch DevOps - SLA

Bài viết này giải thích vai trò của SLA trong ngữ cảnh DevOps. Đầu tiên, trường hợp kinh doanh của SLA được đưa ra. Thứ hai, ảnh hưởng của SLA trong mỗi giai đoạn của quy trình DevOps được xác định.

SLA có cần thiết không?

Nếu một phương pháp mới được thị trường áp dụng, nhiều biện pháp kiểm soát hiện có cũng sẽ bị bãi bỏ. Và thật không may, điều đó cũng đúng với sự ra đời của DevOps. Nhiều tổ chức đã trải nghiệm SLA như một tài liệu đắt tiền không tạo ra bất kỳ sự khác biệt nào trong chất lượng cung cấp dịch vụ† Như được chỉ ra trong Hình 1, đây là một quan điểm rất méo mó về mục đích thực tế của SLA.

Một SLA có thể được sử dụng làm cơ sở thử nghiệm để xác định mức độ mà tổ chức dịch vụ có thể cung cấp chất lượng. Nếu SLA là cách duy nhất để giải quyết chất lượng không bao giờ xảy ra, thì đó không bao giờ là trường hợp với người quản lý cấp dịch vụ và sự trưởng thành của tổ chức dịch vụ. Nếu SLA không chứa bất kỳ tiêu chuẩn chất lượng nào, thì điều này không chứa bất kỳ tiêu chuẩn chất lượng nào, thì điều này nói lên điều gì đó về yêu cầu của khách hàng và sự trưởng thành của quy trình kinh doanh.

Vì vậy, SLA không gì khác hơn là một tài liệu kết hợp các Yêu cầu phi chức năng (NFR) từ góc độ kinh doanh trong Kế hoạch DevOps. Do đó, không có lý do nào để tuyên bố rằng SLA không có quyền tồn tại. Chỉ có thể nói rằng nhà cung cấp thông tin (một tài liệu) không còn ở thời điểm này.

SLA trong kênh

Các tiêu chuẩn dịch vụ như tính khả dụng, năng lực, hiệu suất, bảo mật và tính liên tục có tác động đến thiết kế hoàn chỉnh của một dịch vụ. Các định mức dịch vụ này và các biện pháp cần thiết để đạt được các định mức này phải là một phần của việc xác định trường hợp kinh doanh trong kênh (xem bài viết Kế hoạch DevOps - phân phối). Người ta thường nói rằng không có quan điểm về NFR tại thời điểm đó. Tuy nhiên, đối số này phải được loại bỏ mạnh mẽ, như được nêu trong Hình 1. NFR là một câu hỏi từ doanh nghiệp để kiểm soát rủi ro. Thực hiện hành động đòi hỏi chức năng bổ sung, giúp giảm đáng kể trường hợp kinh doanh của ý tưởng trong kênh. Tuy nhiên, các NFR cấp cao sẽ được đưa vào ý tưởng.

SLA trong lộ trình

Trong ITIL ®, giai đoạn chiến lược dịch vụ cung cấp một khung công tác tuyệt vời dưới dạng Mẫu hoặc Hoạt động kinh doanh (PBA) và Hồ sơ người dùng (UP). Kiến trúc sư cần xác định với các bên liên quan và sử dụng dịch vụ dự kiến ​​(PBA). Do đó, một nhân viên hoạt động (UP) thường sẽ sử dụng tần số cao một dịch vụ và một nhân viên chiến thuật (UP) ở tần suất sử dụng thấp hơn. Đặc biệt, dấu chân dịch vụ trên cơ sở hạ tầng phải được xem xét chặt chẽ để xác định tác động đến cơ sở hạ tầng của dịch vụ. Với sự xuất hiện của các dịch vụ đám mây, những hiệu ứng này nhanh chóng bị tắt tiếng. Tuy nhiên, nó được khuyến khích để xem xét chặt chẽ này. Các khía cạnh đặc biệt như bảo mật là một chủ đề đang diễn ra.

SLA trong kế hoạch phát hành

Rất rõ ràng, đó là thường những thay đổi về cơ sở hạ tầng cần thiết để triển khai phù hợp đều bị lãng quên. Đối với các tổ chức, cơ sở hạ tầng là một phần của nhóm DevOps (cơ sở hạ tầng như mã). Nhóm cơ sở hạ tầng trung tâm thường làm việc thông qua phương pháp tiếp cận thác nước do bản chất của các dịch vụ. Nhóm cơ sở hạ tầng phải tham gia kịp thời và không phải ba ngày trước khi GO-live.

SLA trong giai đoạn mã

Một nhận xét thường được sử dụng của một lập trình viên là SLA dành cho nhóm OPS và không có bất kỳ tác động tích cực hay tiêu cực nào đối với công việc của họ với tư cách là một lập trình viên. Tất nhiên, điều này không đúng. Kiến trúc sư phải chú ý đến từng chu kỳ DevOps hoặc có tác động tích cực đến hiệu suất của dịch vụ. Ít nhất có một danh sách kiểm tra đơn giản như:

  • Khả năng mở rộng (phần mềm có thể mở rộng không?)
  • Hiệu suất (các kế hoạch truy vấn hiển thị quét bảng?)
  • Bảo mật (là mã hóa cần thiết, chính sách bảo mật có được áp dụng không?)
  • Tính khả dụng (quản lý ngoại lệ có được lập trình tốt không?)
  • Chất lượng dữ liệu (cơ chế giao dịch chính xác được sử dụng?)
  • vv

SLA trong giai đoạn xây dựng

Trong giai đoạn xây dựng, các trường hợp kiểm thử đơn vị có thể kiểm tra xem các Quy tắc và Nguyên tắc Chuẩn (SRG) liên quan đến việc sử dụng tối ưu các nguồn lực vật lý có được tuân thủ hay không. Ví dụ, có thể kiểm tra rò rỉ bộ nhớ, nhưng cũng có thể kiểm tra phần gỗ chết trong mã. Kiểm tra hiệu suất sẽ chỉ diễn ra sau khi xây dựng. Không nên quên rằng máy chủ xây dựng cũng phải cung cấp một hiệu suất tốt để nhận ra thời gian đưa ra thị trường. Tiêu chuẩn vàng là quá trình xây dựng có thể không quá 5 phút. Vẫn có những tổ chức xây dựng chỉ sau một đêm với tất cả hậu quả của việc đó.

SLA trong giai đoạn thử nghiệm

Giai đoạn thử nghiệm là hoặc khóa học quan trọng để thử nghiệm NFR. Ví dụ: theo sự kiện hoặc tất cả các sự kiện trong sự kiện danh sách đen được thiết bị màn hình xem xét khi nó đang được sản xuất. Trong đó, kiểm tra hồi quy rất quan trọng. Các cơ sở giám sát thông minh đang được sử dụng trong giai đoạn thử nghiệm (thêm: Kiến trúc DevOps - Giám sát)

SLA trong giai đoạn phát hành

Đường dẫn triển khai phải nhanh và lặp lại. Chắc chắn, nhu cầu phục hồi môi trường sản xuất trong trường hợp xáo trộn nghiêm trọng đòi hỏi rằng đường ống triển khai phải đáp ứng các tiêu chuẩn cao. Ở đây cũng vậy, có một vai trò cho kiến ​​trúc để đảm bảo rằng các cơ chế xây dựng không được sử dụng đúng cách.

SLA trong giai đoạn vận hành

miếng bánh pudding đang bị ăn dở. Nhưng hy vọng, đối với các định mức SLA, chúng đã được đánh giá trong phễu và được kiểm tra trong giai đoạn thử nghiệm. Phản hồi từ các hoạt động sẽ dẫn đến điều chỉnh thường xuyên trong suốt luồng ý tưởng để triển khai.

SLA trong giai đoạn giám sát

Tất cả các tiêu chuẩn SLA nên được quan sát thông qua cơ sở giám sát. Điều này đòi hỏi nhu cầu cao về cơ sở giám sát. Những gì không thể được theo dõi cũng phải được đồng ý.

Vì vậy, SLA có ảnh hưởng đến tất cả các giai đoạn trong quy trình DevOps. Trên thực tế, rất khôn ngoan nếu yêu cầu nhóm DevOps viết một Thỏa thuận mức hoạt động (OLA) trong đó họ nêu rõ cách họ với tư cách là một nhóm sẽ đảm bảo các chỉ tiêu SLA bằng cách xác định các biện pháp đối phó trong các quy trình, sản phẩm và dịch vụ như được mô tả trong Hình 1.

Nhóm LinkedIn

Thảo luận với chúng tôi về bài viết này LinkedIn.

Thông tin thêm

Sách liên quan:

Thực tiễn tốt nhất của DevOps, ISBN: 9789492618078Quản lý dịch vụ nhanh với Scrum, ISBN: 9789071501807

Các khóa đào tạo liên quan:

  • Quỹ DevOps
  • DevOps trong thực tế
  • DevOps Master
  • Masterclass DevOps Operations
  • Masterclass DevOps Phát triển ứng dụng
  • Kiến trúc Masterclass DevOps

Điều liên quan:

Quản lý dịch vụ

Tóm tắt Gói DevOps - SLA và các yêu cầu không hoạt động điều khoản Gói DevOps - SLA và các yêu cầu không hoạt động Mô tả Bài viết này mô tả cách xác định SLA trong một phương pháp DevOps. Thỏa thuận mức dịch vụ (SLA) là thỏa thuận giữa nhà cung cấp dịch vụ CNTT và khách hàng. Nội dung của SLA là về các chỉ tiêu chất lượng được gán cho sản phẩm, quy trình và dịch vụ. Một ví dụ về một tiêu chuẩn SLA cho một ứng dụng là: sẵn có hoặc 99,9% với sự cố 3 tối đa mỗi năm và tối đa 3 giờ ngừng hoạt động. Trong bài viết này, ý nghĩa của dịch vụ thuật ngữ bao gồm sản phẩm. Tác giả Bart de Best Tên nhà xuất bản ITpedia Biểu trưng nhà xuất bản ITpedia

Chia sẻ ITpedia qua

  • Facebook
  • Twitter
  • LinkedIn

Từ khóa » Cách Xây Dựng Sla