Một ứng dụng đang được triển khai trong môi trường sản xuất tiếp tục phát triển ngay cả khi không có tính năng nào được thêm vào. Trình duyệt, hệ thống, thư viện, chứng chỉ, khối lượng và dịch vụ bên thứ ba thay đổi. Người dùng gặp phải các trường hợp không lường trước và các rủi ro bảo mật được đánh giá lại.
Bảo trì ứng dụng tổ chức sự liên tục này. Nó không chỉ giới hạn ở một kho thời gian hay một địa chỉ email. Nó xác định phạm vi, trách nhiệm, ưu tiên, thời hạn xử lý, khả năng phát triển và cách đo lường dịch vụ.
Hướng dẫn này giúp cấu trúc thiết bị. Nó không phải là một mô hình pháp lý; các điều khoản cần được điều chỉnh theo bối cảnh và được các bên xác nhận.
TMA, hỗ trợ, bảo trì và quản trị CNTT: phân biệt các dịch vụ
Bảo trì sửa chữa xử lý các sự cố. Bảo trì dự phòng giảm thiểu rủi ro trước khi sự cố xảy ra: cập nhật, xem xét, kiểm tra sao lưu. Bảo trì phát triển thay đổi sản phẩm. Hỗ trợ đi kèm với người dùng hoặc quản trị viên. Quản trị dịch vụ CNTT bao gồm hoạt động của cơ sở hạ tầng và các dịch vụ kỹ thuật.
TMA, hay bảo trì ứng dụng bên thứ ba, có thể tập hợp nhiều hoạt động này khi chúng được giao cho một nhà cung cấp. Hợp đồng phải nêu rõ những gì được bao gồm. Một lỗi mã, một dữ liệu sai, một máy chủ quá tải và một câu hỏi về việc sử dụng không đòi hỏi cùng một kỹ năng cũng như mức độ cam kết giống nhau.
Xác định phạm vi trước hạn chót
Phạm vi bao gồm các ứng dụng, phiên bản, môi trường, giao diện, các xử lý đã lên kế hoạch, dịch vụ bên thứ ba và giờ sử dụng. Nó chỉ rõ ai quản lý đám mây, cơ sở dữ liệu, chứng chỉ, các bản sao lưu, DNS, máy trạm người dùng và các nhà cung cấp bên ngoài.
Cũng cần liệt kê các loại trừ: hệ thống không được tài liệu hóa, thành phần không được hỗ trợ, truy cập không được cung cấp, sửa đổi trực tiếp bởi bên thứ ba hoặc môi trường thử nghiệm không có. Một loại trừ phải dẫn đến một kế hoạch giảm thiểu, không trở thành một lý do vĩnh viễn.
Xây dựng một ma trận ưu tiên
Một ưu tiên được xác định bởi tác động, phạm vi và sự tồn tại của một giải pháp thay thế. Một ví dụ chung:
| Cấp độ | Tình huống | Ví dụ | Mục tiêu ban đầu |
|---|---|---|---|
| P1 phê bình | Dịch vụ hoặc chức năng quan trọng không khả dụng, rủi ro về dữ liệu/an ninh | không thể xử lý đơn hàng | hỗ trợ và bộ phận xử lý sự cố ngay lập tức theo phạm vi bảo hiểm |
| Đô trưởng P2 | Chức năng quan trọng bị suy giảm, khả năng tránh né hạn chế | nhập khẩu bị chặn cho một đội | chẩn đoán ưu tiên |
| Tiêu chuẩn P3 | Bất thường giới hạn, đường vòng chấp nhận được | lỗi hiển thị hoặc quy tắc phụ | lập kế hoạch trong bảo trì |
| P4 thứ | mức độ khó chịu thấp hoặc yêu cầu cải thiện | tiêu đề, sự thoải mái, tối ưu hóa | danh sách công việc tồn đọng có thể phát triển |
Phẩm chất phải có khả năng được xem xét lại sau chẩn đoán. Một triệu chứng chỉ thấy bởi một người dùng có thể tiết lộ một lỗi dữ liệu toàn cục; một cảnh báo ấn tượng có thể không có tác động.
Đừng nhầm lẫn các thời hạn
Thời gian bắt đầu tiếp nhận tương ứng với lúc bắt đầu điều trị. Thời gian chẩn đoán nhằm vào việc hiểu biết ban đầu. Thời gian hồi phục đưa dịch vụ trở lại mức chấp nhận được, đôi khi bằng cách giải quyết tạm thời. Thời gian khắc phục mang lại sự sửa chữa cuối cùng.
Hứa hẹn một giải pháp cố định cho mọi bất thường hiếm khi thực tế, vì nguyên nhân có thể phụ thuộc vào bên thứ ba hoặc cần phải di chuyển. Một cam kết vững chắc hơn là tập trung vào huy động, truyền thông, khôi phục và leo thang.
Đặt giờ phục vụ
Một ứng dụng được sử dụng từ thứ Hai đến thứ Sáu không nhất thiết phải có dịch vụ trực 24/7. Ngược lại, các quy trình ban đêm, người dùng quốc tế hoặc các chiến dịch có thể tạo ra các giai đoạn quan trọng ngoài giờ làm việc.
Bìa phải phân biệt:
- tiếp nhận và ghi nhận các yêu cầu;
- giám sát tự động;
- chăm sóc nhân đạo ;
- can thiệp kỹ thuật ;
- sẵn sàng của các nhà quyết định lĩnh vực kinh doanh.
Một trách nhiệm trực ca mà không có quyền truy cập, tài liệu, giám sát hay quyền ra quyết định thì hầu như không mang lại sự bảo vệ nào.
Tổ chức kênh nhập và leo núi
Mỗi yêu cầu phải nhận được một định danh, một mức ưu tiên, một môi trường, một tác động, các yếu tố tái hiện và một người yêu cầu. Các trường hợp khẩn cấp sử dụng một kênh rõ ràng; một email gửi vào ban đêm không được giả định sẽ kích hoạt trực tuần nếu cơ chế này chưa được thỏa thuận.
Việc leo thang chính xác được liên hệ khi sự cố vượt quá phạm vi, liên quan đến nhà cung cấp, yêu cầu quyết định kinh doanh hoặc trở thành khủng hoảng. Thông tin liên lạc và vai trò được xem xét định kỳ.
Sơ đồ trình bày bảy bước liên tiếp. Việc khôi phục dịch vụ không kết thúc vòng lặp: phân tích và phòng ngừa biến mỗi sự cố thành cải tiến có thể đo lường.
- Phát hiện : phát hiện bất thường thông qua giám sát, nhật ký hoặc báo cáo của người dùng.
- Đối tượng đủ điều kiện: đo lường tác động, phạm vi, mức độ quan trọng và các rủi ro liên quan.
- Chứa: giới hạn sự lây lan và bảo vệ dữ liệu hoặc các hành trình vẫn còn có sẵn.
- Khôi phục: đưa dịch vụ trở lại mức chấp nhận được, nếu cần bằng cách vượt qua có kiểm soát.
- Phân tích : xác định các nguyên nhân kỹ thuật và tổ chức dựa trên các sự kiện.
- Cảnh báo : thêm các bản vá, cảnh báo, kiểm tra hoặc quy trình giúp giảm tái phát.
- Cải thiện : theo dõi các hành động và điều chỉnh thiết bị bảo trì trong quá trình xem xét dịch vụ.
Dự kiến một năng lực, không chỉ là một tỉ lệ hàng ngày
Bảo trì thường xuyên được hưởng một công suất dự phòng. Nó có thể dưới dạng gói cố định, số ngày hàng tháng, mức tiêu thụ tối thiểu hoặc ngân sách thực tế có giới hạn. Mỗi mô hình phân bổ rủi ro về khả năng sẵn có của nguồn lực khác nhau.
Ngân sách phải phân biệt:
- nền tảng dịch vụ và quản trị;
- giám sát và trực ban;
- bản vá hiện tại;
- cập nhật phòng ngừa;
- các tiến triển đã được lập kế hoạch;
- công trường đặc biệt.
Trộn tất cả trong một phong bì duy nhất thường dẫn đến hy sinh các bản cập nhật để ưu tiên các yêu cầu có thể nhìn thấy.
Duy trì một chính sách phiên bản
Hợp đồng mô tả cách theo dõi các phụ thuộc, lỗ hổng và kết thúc hỗ trợ. Các bản cập nhật nhỏ được kiểm tra định kỳ; các phiên bản lớn được nghiên cứu và lập kế hoạch dự án.
Mục tiêu là tránh sự luân phiên giữa tình trạng tê liệt và di cư khẩn cấp. Một ngân sách phòng ngừa làm mịn nỗ lực và duy trì khả năng phát triển.
Đo lường một dịch vụ hữu ích
Số lượng vé đã đóng không đủ. Các chỉ số có thể bao gồm:
- tính khả dụng của các hành trình quan trọng;
- thời gian phát hiện;
- thời gian tiếp nhận và phục hồi theo thứ tự ưu tiên;
- tỷ lệ mở cửa trở lại;
- sự cố tái diễn;
- những thay đổi đã gây ra sự cố;
- tuổi của backlog bảo mật;
- tiêu thụ sửa chữa, phòng ngừa và tiến triển;
- sự hài lòng của các đối tác giao tiếp.
Các biện pháp cần được diễn giải. Sự gia tăng số lượng vé có thể phản ánh khả năng phát hiện tốt hơn, không phải sự suy giảm.
Tổ chức các cuộc rà soát dịch vụ
Một bản đánh giá hàng tháng hoặc hàng quý xem xét các sự cố, năng lực, rủi ro, các phiên bản và lộ trình. Nó xác định các nguyên nhân lặp lại và quyết định các hành động phòng ngừa. Các vấn đề về ngân sách được thảo luận dựa trên bằng chứng, không chỉ trong trường hợp khẩn cấp.
Báo cáo phân công từng hành động, thời hạn và tiêu chí kết thúc. Các sai lệch về cam kết được phân tích để cải thiện quy trình.
Chuẩn bị lối ra ngay từ khi vào
Thiết bị phải bao gồm khả năng đảo ngược: tài liệu, quyền truy cập của khách hàng, xuất các vé, quyền sở hữu tài khoản, chuyển giao kiến thức và luân phiên các bí mật. Sự chuẩn bị này bảo vệ khách hàng và cũng cải thiện chất lượng hàng ngày.
Một hợp đồng phù hợp với mức độ quan trọng thực sự
Sự sẵn sàng hoàn hảo không tồn tại và bất kỳ yêu cầu nào cũng đều có chi phí về kiến trúc, công cụ và tổ chức. Hợp đồng tốt làm rõ sự đánh đổi này. Nó xác định những gì là quan trọng, cách dịch vụ được khôi phục và cách rủi ro được giảm thiểu theo thời gian.
Partitech đảm bảo bảo trì sửa chữa, phát triển, lưu trữ, quản lý CNTT và, tùy theo nhu cầu, các ca trực. Chúng tôi có thể tiếp nhận một dự án do bên thứ ba phát triển và xây dựng một khung dịch vụ phù hợp với thực tế sử dụng của nó.
Để tìm hiểu sâu hơn về quy trình, hãy tham khảo phương pháp để tiếp nhận bảo trì một ứng dụng hiện có, chuẩn bị tiếp tục và phục hồi hoạt động và học cách tính toán TCO của một ứng dụng trong năm năm. Khám phá thêm ưu đãi Bảo trì, phát triển và lưu trữ của Partitech.
Tham chiếu chính thức
Tài liệu tham khảo được tra cứu vào ngày 17 tháng 8 năm 2026 :