Trong các ấn phẩm về Habré, tôi đã viết về kinh nghiệm xây dựng quan hệ đối tác với nhóm của mình ( nói về cách soạn thảo thỏa thuận hợp tác khi bắt đầu kinh doanh mới để việc kinh doanh không bị tan vỡ). Và bây giờ tôi muốn nói về cách xây dựng mối quan hệ đối tác với khách hàng, vì nếu không có họ thì sẽ không có gì có thể đổ vỡ. Tôi hy vọng bài viết này sẽ hữu ích cho các bạn khởi nghiệp đang bắt đầu bán sản phẩm của mình cho các doanh nghiệp lớn.
Tôi hiện đang điều hành một công ty khởi nghiệp có tên là phòng thí nghiệm kỹ thuật số MONQ, nơi tôi và nhóm của mình đang phát triển một sản phẩm nhằm tự động hóa các quy trình hỗ trợ và vận hành CNTT của công ty. Thâm nhập thị trường không phải là một nhiệm vụ dễ dàng và chúng tôi bắt đầu với một ít bài tập về nhà, tìm hiểu thông qua các chuyên gia thị trường, đối tác và tiến hành phân khúc thị trường. Câu hỏi chính là phải hiểu “chúng ta có thể chữa lành nỗi đau của ai tốt nhất?”
Các ngân hàng lọt vào TOP 3 phân khúc. Và tất nhiên, người đầu tiên trong danh sách là Tinkoff và Sberbank. Khi chúng tôi đến thăm các chuyên gia về thị trường ngân hàng, họ nói: hãy giới thiệu sản phẩm của bạn ở đó và con đường vào thị trường ngân hàng sẽ rộng mở. Chúng tôi đã cố gắng tham gia cả ở đó và ở đó, nhưng thất bại đang chờ đợi chúng tôi ở Sberbank, và những người ở Tinkoff hóa ra lại cởi mở hơn nhiều trong việc giao tiếp hiệu quả với các công ty khởi nghiệp Nga (có thể do Sber vào thời điểm đó gần một tỷ đối thủ cạnh tranh phương Tây của chúng tôi). Trong vòng một tháng, chúng tôi đã bắt đầu một dự án thí điểm. Nó diễn ra như thế nào, hãy đọc tiếp.
Chúng tôi đã giải quyết các vấn đề về vận hành và giám sát trong nhiều năm, hiện chúng tôi đang triển khai sản phẩm của mình trong khu vực công, bảo hiểm, ngân hàng, công ty viễn thông, một triển khai là với một hãng hàng không (trước dự án, chúng tôi thậm chí không nghĩ rằng hàng không là một ngành phụ thuộc vào CNTT và Bây giờ chúng tôi thực sự hy vọng, bất chấp COVID, rằng công ty sẽ nổi lên và phát triển).
Sản phẩm chúng tôi tạo ra thuộc về phần mềm doanh nghiệp, phân khúc AIOps (Trí tuệ nhân tạo cho hoạt động CNTT hoặc ITOps). Mục tiêu chính của việc triển khai các hệ thống như mức độ hoàn thiện quy trình trong công ty tăng lên:
- Dập tắt đám cháy: xác định sự cố, xóa luồng cảnh báo khỏi các mảnh vụn, phân công nhiệm vụ và sự cố cho những người chịu trách nhiệm;
- Tăng hiệu quả dịch vụ CNTT: giảm thời gian giải quyết sự cố, chỉ ra nguyên nhân lỗi, tăng tính minh bạch về tình trạng CNTT;
- Tăng hiệu quả kinh doanh: giảm lượng lao động thủ công, giảm thiểu rủi ro, tăng lòng trung thành của khách hàng.
Theo kinh nghiệm của chúng tôi, các ngân hàng đều gặp phải những “nỗi đau” sau đây khi giám sát tất cả các cơ sở hạ tầng CNTT lớn:
- “ai biết cái gì”: có nhiều bộ phận kỹ thuật, hầu hết mọi người đều có ít nhất một hệ thống giám sát và hầu hết đều có nhiều hơn một hệ thống;
- Cảnh báo “đàn muỗi”: mỗi hệ thống tạo ra hàng trăm cảnh báo và tấn công tất cả những người chịu trách nhiệm về chúng (đôi khi cũng giữa các phòng ban). Rất khó để liên tục duy trì trọng tâm kiểm soát đối với từng thông báo, tính cấp bách và tầm quan trọng của chúng bị san bằng do số lượng lớn;
- các ngân hàng lớn - các nhà lãnh đạo ngành không chỉ muốn liên tục giám sát hệ thống của họ, biết nơi nào có lỗi mà còn muốn biết điều kỳ diệu thực sự của AI - làm cho hệ thống tự giám sát, tự dự đoán và tự sửa lỗi.
Khi đến cuộc họp đầu tiên tại Tinkoff, chúng tôi ngay lập tức được thông báo rằng họ không gặp vấn đề gì trong việc giám sát và không có gì gây tổn hại cho họ, và câu hỏi chính là: “Chúng tôi có thể cung cấp những gì cho những người đang làm tốt?”
Cuộc trò chuyện kéo dài, chúng tôi đã thảo luận về cách xây dựng các dịch vụ vi mô của họ, cách các bộ phận hoạt động, vấn đề cơ sở hạ tầng nào nhạy cảm hơn, ít nhạy cảm hơn đối với người dùng, “điểm mù” ở đâu, mục tiêu và SLA của họ là gì.
Nhân tiện, SLA của ngân hàng thực sự ấn tượng. Ví dụ: sự cố về tính khả dụng của mạng ưu tiên XNUMX có thể chỉ mất vài phút để giải quyết. Tất nhiên, chi phí do lỗi và thời gian ngừng hoạt động ở đây là rất ấn tượng.
Kết quả là chúng tôi đã xác định được một số lĩnh vực hợp tác:
- Giai đoạn đầu tiên là giám sát chung để tăng tốc độ giải quyết sự cố
- giai đoạn thứ hai là tự động hóa quy trình để giảm thiểu rủi ro và giảm chi phí cho việc mở rộng quy mô bộ phận CNTT.
Một số “điểm trắng” chỉ có thể được sơn bằng màu sáng của cảnh báo bằng cách xử lý thông tin từ một số hệ thống giám sát, vì không thể lấy số liệu trực tiếp; cũng cần phải tập trung dữ liệu từ các hệ thống giám sát khác nhau vào “một màn hình” để để hiểu bức tranh tổng thể về những gì đang xảy ra. “Ô” phù hợp với nhiệm vụ này và chúng tôi đã đáp ứng được những yêu cầu này.
Theo chúng tôi, một điều rất quan trọng trong mối quan hệ với khách hàng là sự trung thực. Sau cuộc trò chuyện đầu tiên và tính toán chi phí giấy phép, người ta nói rằng vì chi phí quá thấp nên có thể đáng mua giấy phép ngay lập tức (so với Dynatrace Klyuch-Astrom trong bài viết trên về ngân hàng xanh, của chúng tôi giấy phép có giá không phải một phần ba tỷ mà là 12 nghìn rúp mỗi tháng cho 1 gigabyte, đối với Sber, nó sẽ rẻ hơn nhiều lần). Nhưng chúng tôi ngay lập tức nói với họ những gì chúng tôi có và những gì chúng tôi không có. Có lẽ đại diện bán hàng của một nhà tích hợp lớn có thể nói “vâng, chúng tôi có thể làm mọi thứ, tất nhiên là mua giấy phép của chúng tôi,” nhưng chúng tôi quyết định đặt tất cả các thẻ của mình lên bàn. Vào thời điểm ra mắt, hộp của chúng tôi chưa tích hợp với Prometheus và một phiên bản mới với hệ thống con tự động hóa sắp được phát hành, nhưng chúng tôi vẫn chưa giao nó cho khách hàng.
Dự án thí điểm bắt đầu, ranh giới của nó đã được xác định và chúng tôi có thời hạn 2 tháng. Các nhiệm vụ chính là:
- chuẩn bị phiên bản mới của nền tảng và triển khai nó trong cơ sở hạ tầng của ngân hàng
- kết nối 2 hệ thống giám sát (Zabbix và Prometheus);
- gửi thông báo cho những người chịu trách nhiệm trong Slack và qua SMS;
- chạy các tập lệnh tự động sửa lỗi.
Tháng đầu tiên của dự án thí điểm được dành để chuẩn bị phiên bản mới của nền tảng ở chế độ siêu nhanh cho nhu cầu của dự án thí điểm. Phiên bản mới ngay lập tức bao gồm tích hợp với Prometheus và tự động phục hồi. Nhờ đội ngũ phát triển của chúng tôi, họ đã không ngủ nhiều đêm mà vẫn đưa ra những gì đã hứa mà không bỏ lỡ thời hạn cho những cam kết khác đã đưa ra trước đó.
Trong khi thiết lập chương trình thí điểm, chúng tôi đã gặp phải một vấn đề mới có thể đóng dự án trước thời hạn: để gửi thông báo đến các trình nhắn tin tức thời và qua SMS, chúng tôi cần các kết nối đến và đi tới máy chủ Microsoft Azure (vào thời điểm đó chúng tôi sử dụng nền tảng này để gửi thông báo tới Slack) và dịch vụ gửi SMS bên ngoài. Nhưng trong dự án này, an toàn là trọng tâm đặc biệt. Theo chính sách của ngân hàng, những “lỗ hổng” như vậy không thể mở được trong bất kỳ trường hợp nào. Mọi thứ phải hoạt động theo một vòng khép kín. Chúng tôi đã được đề nghị sử dụng API của các dịch vụ nội bộ của riêng mình để gửi thông báo tới Slack và qua SMS, nhưng chúng tôi không có cơ hội kết nối các dịch vụ đó ngay lập tức.
Một buổi tối tranh luận với nhóm phát triển đã kết thúc với việc tìm kiếm giải pháp thành công. Sau khi lục lọi các hồ sơ tồn đọng, chúng tôi tìm thấy một nhiệm vụ mà chúng tôi chưa bao giờ có đủ thời gian và mức độ ưu tiên - tạo ra một hệ thống plug-in để nhóm triển khai hoặc khách hàng có thể tự viết các tiện ích bổ sung, mở rộng khả năng của nền tảng.
Nhưng chúng tôi chỉ còn đúng một tháng nữa, trong thời gian đó chúng tôi phải cài đặt mọi thứ, định cấu hình và triển khai tự động hóa.
Theo Sergei, kiến trúc sư trưởng của chúng tôi, phải mất ít nhất một tháng để triển khai hệ thống plug-in.
Chúng tôi đã không có thời gian...
Chỉ có một giải pháp duy nhất - hãy đến gặp khách hàng và kể mọi chuyện như hiện tại. Cùng nhau thảo luận về sự thay đổi thời hạn. Va no đa hoạt động. Chúng tôi được cho thêm 2 tuần. Họ cũng có thời hạn và nghĩa vụ nội bộ riêng để trình bày kết quả, nhưng họ có 2 tuần dự bị. Cuối cùng, chúng tôi đặt mọi thứ lên hàng đầu. Không thể lộn xộn được. Sự trung thực và cách tiếp cận hợp tác một lần nữa đã được đền đáp.
Kết quả của cuộc thí điểm đã thu được một số kết quả và kết luận kỹ thuật quan trọng:
Chúng tôi đã thử nghiệm chức năng mới để xử lý cảnh báo
Hệ thống được triển khai bắt đầu nhận chính xác các cảnh báo từ Prometheus và nhóm chúng lại. Cảnh báo về sự cố từ ứng dụng khách Prometheus xuất hiện cứ sau 30 giây (không bật nhóm theo thời gian) và chúng tôi tự hỏi liệu có thể nhóm chúng trong chính “chiếc ô” hay không. Hóa ra là có thể - việc thiết lập xử lý cảnh báo trong nền tảng được thực hiện bằng một tập lệnh. Điều này giúp bạn có thể triển khai hầu hết mọi logic để xử lý chúng. Chúng tôi đã triển khai logic tiêu chuẩn trong nền tảng dưới dạng mẫu - nếu bạn không muốn nghĩ ra thứ gì đó của riêng mình, bạn có thể sử dụng logic làm sẵn.
Giao diện “kích hoạt tổng hợp”. Thiết lập xử lý cảnh báo từ hệ thống giám sát được kết nối
Xây dựng trạng thái “sức khỏe” của hệ thống
Dựa trên các cảnh báo, các sự kiện giám sát đã được tạo ra có ảnh hưởng đến tình trạng của các đơn vị cấu hình (CU). Chúng tôi đang triển khai mô hình dịch vụ tài nguyên (RSM), có thể sử dụng CMDB nội bộ hoặc kết nối với mô hình bên ngoài - trong dự án thí điểm, khách hàng không kết nối CMDB của chính mình.
Giao diện để làm việc với mô hình dịch vụ tài nguyên. Phi công RSM.
Chà, trên thực tế, khách hàng cuối cùng cũng có một màn hình giám sát duy nhất, nơi có thể nhìn thấy các sự kiện từ các hệ thống khác nhau. Hiện tại, hai hệ thống được kết nối với “chiếc ô” - Zabbix và Prometheus, cũng như hệ thống giám sát nội bộ của chính nền tảng này.
Giao diện phân tích. Màn hình giám sát đơn.
Ra mắt tự động hóa quy trình
Các sự kiện giám sát đã kích hoạt việc khởi chạy các hành động được định cấu hình trước - gửi cảnh báo, chạy tập lệnh, sự cố đăng ký/làm giàu - hành động sau chưa được thử với ứng dụng khách cụ thể này, bởi vì trong dự án thí điểm không có sự tích hợp với bàn dịch vụ.
Giao diện cài đặt hành động. Gửi thông báo tới Slack và khởi động lại máy chủ.
Chức năng sản phẩm mở rộng
Khi thảo luận về các tập lệnh tự động hóa, khách hàng đã yêu cầu hỗ trợ bash và một giao diện trong đó các tập lệnh này có thể được cấu hình một cách thuận tiện. Phiên bản mới đã làm được nhiều hơn một chút (khả năng viết các cấu trúc logic chính thức trong Lua với sự hỗ trợ cho cURL, SSH và SNMP) và triển khai chức năng cho phép bạn quản lý vòng đời của tập lệnh (tạo, chỉnh sửa, kiểm soát phiên bản , xóa và lưu trữ).
Giao diện để làm việc với các tập lệnh tự động sửa lỗi. Tập lệnh khởi động lại máy chủ thông qua SSH.
Những phát hiện chính
Trong quá trình thí điểm, các câu chuyện của người dùng cũng được tạo để cải thiện chức năng hiện tại và tăng giá trị cho khách hàng, sau đây là một số câu chuyện trong số đó:
- triển khai khả năng chuyển tiếp các biến trực tiếp từ cảnh báo đến tập lệnh tự động sửa lỗi;
- thêm ủy quyền cho nền tảng thông qua Active Directory.
Và chúng tôi đã nhận được nhiều thách thức toàn cầu hơn - để “xây dựng” sản phẩm với các khả năng khác:
- tự động xây dựng mô hình dịch vụ tài nguyên dựa trên ML, thay vì các quy tắc và tác nhân (có thể là thách thức chính hiện nay);
- hỗ trợ các ngôn ngữ logic và kịch bản bổ sung (và đây sẽ là JavaScript).
Trong quan điểm của tôi, điều quan trọng nhấtNhững gì thí điểm này cho thấy là hai điều:
- Quan hệ đối tác với khách hàng là chìa khóa dẫn đến hiệu quả, khi giao tiếp hiệu quả được xây dựng trên cơ sở trung thực và cởi mở, đồng thời khách hàng trở thành thành viên của một nhóm đạt được kết quả quan trọng trong thời gian ngắn.
- Trong mọi trường hợp, không cần thiết phải “tùy chỉnh” và xây dựng “nạng” - chỉ các giải pháp hệ thống. Tốt hơn là bạn nên dành thêm một chút thời gian nhưng hãy tạo ra một giải pháp hệ thống để các khách hàng khác sử dụng. Nhân tiện, đây là điều đã xảy ra, hệ thống plugin và việc loại bỏ sự phụ thuộc vào Azure đã mang lại giá trị bổ sung cho các khách hàng khác (xin chào, Luật Liên bang 152).
Nguồn: www.habr.com