“Không có sự đổi mới và sáng tạo nào mà không có thất bại. Chấm hết.” – Brené Brown

Trong lĩnh vực Công nghệ thông tin ngày nay, có vẻ như không thể nào không có ai đó sử dụng một số biến thể của từ đổi mới trong năm phút. Chúng ta liên tục được bảo rằng chúng ta cần phải đổi mới để duy trì khả năng cạnh tranh và duy trì sự phù hợp. Tôi không muốn tốn thời gian tranh luận về tầm quan trọng của đổi mới, bởi vì nếu bạn đang đọc bài viết này thì có lẽ bạn đã hiểu được tầm quan trọng của nó.

Điều tôi muốn tập trung vào là vai trò của thất bại trong đổi mới. Một trong những rào cản lớn nhất đối với đổi mới là nỗi sợ thất bại. Tất cả chúng ta đều đã trải qua một số mức độ thất bại trong cuộc sống của mình và những sai lầm tốn kém có thể đặc biệt đáng nhớ. Để tạo ra một nền văn hóa thúc đẩy đổi mới, chúng ta cần tạo ra một môi trường giảm thiểu chi phí liên quan đến thất bại – có thể là chi phí tài chính, chi phí thời gian hoặc chi phí danh tiếng. Đây là lý do tại sao một trong những nguyên lý cốt lõi của kiến ​​trúc ứng dụng hiện đại là “thất bại nhanh chóng”. Nói một cách đơn giản, điều này có nghĩa là xác định lỗi nhanh chóng và điều chỉnh. Ý tưởng là một quy trình hoặc giả định bị lỗi sẽ tốn kém hơn để sửa chữa nếu nó tồn tại trong hệ thống càng lâu. Với các quy trình thác nước truyền thống, lỗi đó có thể tồn tại và không được phát hiện trong nhiều tháng trong quá trình phát triển và trong một số trường hợp, thậm chí còn tồn tại trong quá trình sản xuất.

Mặc dù lợi ích của fail fast có thể dễ dàng thấy được, nhưng việc triển khai nó có thể khó hơn một chút. Nó liên quan đến việc hợp lý hóa không chỉ quy trình phát triển mà còn cả quy trình xây dựng, quy trình phát hành và có công cụ đo lường phù hợp trong suốt quá trình từ phát triển đến sản xuất. Phần cuối cùng này, công cụ đo lường, là trọng tâm của bài viết này. Công cụ đo lường có nghĩa là giám sát một hệ thống để cho phép người vận hành:

• Xem trạng thái hiện tại
• Xác định hiệu suất ứng dụng
• Phát hiện khi có điều gì đó không hoạt động như mong đợi

Mặc dù nhu cầu về công cụ luôn hiện hữu, các nhà phát triển thường phải đối mặt với các mốc thời gian khó khăn và các lĩnh vực tính năng đầu tiên có xu hướng bị cắt giảm là thử nghiệm và công cụ. Điều này có thể giúp ích trong ngắn hạn, nhưng thường dẫn đến tốn kém hơn về lâu dài, cả về mặt tài chính và trải nghiệm của người dùng cuối.

IBM Instana là một công cụ cung cấp khả năng quan sát toàn bộ hệ thống, hỗ trợ hơn 250 công nghệ khác nhau. Điều này có nghĩa là bạn có thể triển khai Instana vào môi trường và bắt đầu thấy thông tin có giá trị mà không cần bất kỳ thay đổi mã nào. Nếu bạn đang hỗ trợ các ứng dụng dựa trên web, bạn cũng có thể đưa mọi thứ đi xa hơn bằng cách bao gồm các tham chiếu tập lệnh cơ bản trong mã để có được thông tin chi tiết từ số liệu thống kê của khách hàng.

Thông báo hỗ trợ Instana trên Nền tảng được Dell xác thực cho Red Hat OpenShift

Có thể cài đặt IBM Instana vào Nền tảng được Dell xác thực cho Red Hat OpenShift bằng Operator, Helm Chart hoặc Tệp YAML.

Cách đơn giản nhất là sử dụng Toán tử. Bao gồm các bước sau:

1. Tạo dự án instana-agent
2. Thiết lập quyền chính sách cho tài khoản dịch vụ instana-agent
3. Cài đặt trình điều hành
4. Áp dụng Cấu hình toán tử bằng cách sử dụng tệp YAML tài nguyên tùy chỉnh

Bạn có thể cấu hình IBM Instana để trỏ đến điểm cuối đám mây của IBM. Hoặc đối với môi trường bảo mật cao, bạn có thể chọn kết nối đến điểm cuối IBM Instana riêng được lưu trữ nội bộ.

Hình 1. Chế độ xem cơ sở hạ tầng của OpenShift Cluster

Sau khi cấu hình, tác nhân IBM Instana bắt đầu gửi dữ liệu đến điểm cuối để phân tích. Chế độ xem đồ họa trong Hình 1 cho thấy tình trạng chung của cụm Kubernetes và nút mà mỗi tài nguyên nằm trên đó. Các tài nguyên ở trạng thái bình thường có màu xám: bất kỳ tài nguyên nào cần chú ý sẽ xuất hiện ở một màu khác.

Hình 2: Chế độ xem cụm

Chúng ta cũng có thể xem các số liệu thống kê trên toàn cụm, bao gồm số liệu thống kê CPU và Bộ nhớ. Các biểu đồ được đồng bộ theo thời gian, vì vậy nếu bạn làm nổi bật một khu vực nhất định hoặc thu hẹp khoảng thời gian, tất cả các biểu đồ vẫn nằm trong cùng một bối cảnh. Điều này giúp dễ dàng xác định mối tương quan giữa các số liệu thống kê và sự kiện khác nhau.

Hình 3: Chế độ xem cuộc gọi ứng dụng

Việc xem các cuộc gọi ứng dụng cho phép bạn xem hiệu suất của một ứng dụng nhất định theo thời gian. Có thể thu hẹp xuống mức chi tiết một giây có nghĩa là bạn thực sự có thể theo dõi các cuộc gọi riêng lẻ qua hệ thống và xem những thứ như các tham số được truyền trong cuộc gọi. Điều này có thể cực kỳ hữu ích để khắc phục sự cố ứng dụng không liên tục.

Hình 4: Chế độ xem Phụ thuộc ứng dụng

Chế độ xem phụ thuộc cung cấp cho bạn biểu diễn đồ họa của tất cả các thành phần trong một hệ thống và cách chúng liên quan đến nhau, trong sơ đồ phụ thuộc. Điều này cực kỳ quan trọng trong thiết kế ứng dụng hiện đại vì khi bạn triển khai nhiều dịch vụ tập trung hơn, thường được tạo bởi các nhóm DevOps khác nhau, có thể khó theo dõi những dịch vụ nào đang được kết hợp với nhau.

Hình 5: Dấu vết ngăn xếp ứng dụng

Theo dõi ngăn xếp ứng dụng cho phép bạn duyệt qua ngăn xếp của ứng dụng để xem những lệnh gọi nào đã được thực hiện và thời gian hoàn thành mỗi lệnh gọi. Biết rằng tải trang mất năm giây có thể giúp chỉ ra sự cố, nhưng có thể duyệt qua ngăn xếp và xác định rằng 4,8 giây đã được dành để chạy truy vấn cơ sở dữ liệu (và chính xác đó là truy vấn nào) có nghĩa là bạn có thể dành ít thời gian hơn để khắc phục sự cố, vì bạn đã biết chính xác những gì cần sửa.