Xin chào! Tên tôi là Pasha Chernyak, tôi là nhà phát triển hàng đầu tại QIWI và hôm nay tôi muốn nói về điều không thể tránh khỏi. Về di sản.
Hãy bắt đầu với câu hỏi: Legacy service là gì? Dịch vụ cũ có phải là dịch vụ mà nhà phát triển đã không chạm tới trong một tuần/tháng/năm không? Hay đó là một dịch vụ được viết bởi một lập trình viên ít kinh nghiệm hơn, chẳng hạn như bạn, nhưng cách đây một năm? Và bây giờ bạn ngầu hơn và có nhiều kinh nghiệm hơn. Hay dịch vụ Legacy là dịch vụ mà bạn đã quyết định không bao giờ cam kết nữa và đang dần chuẩn bị dịch vụ thay thế? Trong mọi trường hợp, việc để một dịch vụ như vậy không được giám sát và không cập nhật là một quả bom hẹn giờ có thể phát nổ sau này.
Trước khi chuyển sang cách QIWI làm việc với các dịch vụ Legacy của chúng tôi, tôi sẽ cho bạn biết cách chúng tôi đưa các dịch vụ trong Ví vào trật tự. Trong hai năm nay tôi đã chịu trách nhiệm về hiệu suất của nó. Nếu có vấn đề gì họ luôn gọi cho tôi trước. Tôi thường không đủ can đảm để gọi cho người khác vào lúc 11 giờ tối, vì vậy tôi phải ngồi xuống và tìm hiểu tất cả các dịch vụ trên miền của chúng tôi.
Nhưng tôi cũng như bất kỳ người nào, thích ngủ vào ban đêm nên cố gắng giải quyết sự bóc lột: “Các bạn, sao các bạn lại gọi cho tôi?” Tôi nhận được một câu trả lời khá ngắn gọn như “Còn ai nữa?” Bởi vì tôi sửa chữa các dịch vụ và đơn giản là mọi người không biết phải gọi cho ai.
Do đó, tại một trong những buổi xem xét lại của nhóm phụ trợ Ví, chúng tôi đã quyết định rằng chúng tôi cần tạo một dấu hiệu với danh sách các dịch vụ, dịch vụ vi mô và ví nguyên khối cũng như những người chịu trách nhiệm về chúng. Các dấu hiệu nói chung là hữu ích, trong giới hạn hợp lý.
Ngoài thông tin về ai chịu trách nhiệm về việc gì, còn có câu trả lời cho các câu hỏi: ai là chủ sở hữu dịch vụ, ai chịu trách nhiệm về sự phát triển, kiến trúc và vòng đời của nó. Những người chịu trách nhiệm về dịch vụ này là những người có thể sửa chữa nó nếu có chuyện gì xảy ra. Chủ sở hữu dịch vụ có quyền để lại +2 trong các cam kết, những người chịu trách nhiệm cũng phải có mặt tại buổi đánh giá trước khi dịch vụ này chấp nhận một cam kết mới.
Theo thời gian, các phương pháp thực hành mới bắt đầu được áp dụng, chẳng hạn như di chuyển sang Kubernetes, tất cả các loại kiểu kiểm tra, lỗi phát hiện, ktlint, sự hiện diện của nhật ký trong Kibana, dịch vụ tự động phát hiện thay vì chỉ định trực tiếp địa chỉ và những thứ hữu ích khác. Và ở mọi nơi, bàn của chúng tôi cho phép chúng tôi duy trì mức độ phù hợp của các dịch vụ của mình. Đối với chúng tôi, đây là một loại danh sách kiểm tra cho biết dịch vụ này có thể thực hiện được điều này, nhưng nó vẫn chưa làm được. Nhưng chúng tôi đã tiếp tục, nhận ra rằng chúng tôi thiếu thông tin về các dịch vụ mà chúng tôi giám sát, vị trí của các nguồn dịch vụ , nơi các nhiệm vụ lắp ráp được khởi chạy trong TeamCity, cách chúng được triển khai, nơi lưu trữ các nguồn thử nghiệm end2end, ảnh từ các phiên chuẩn bị về kiến trúc, về các quyết định được đưa ra. Lý tưởng nhất là tôi muốn tất cả thông tin này nằm ở đâu đó và có sẵn khi cần. Vì vậy, bảng hiệu của chúng tôi đã trở thành điểm khởi đầu để tìm kiếm thông tin.
Nhưng QIWI dù vẫn giữ tinh thần của một công ty khởi nghiệp nhưng lại là một công ty lớn. Chúng tôi đã 12 tuổi và các đội đang thay đổi: người ra đi, người đến, đội mới được thành lập. Và chúng tôi đã phát hiện ra một số dịch vụ trên miền của mình mà chúng tôi đã kế thừa. Một số đến từ các nhà phát triển từ các nhóm khác, một số đơn giản là có liên quan gián tiếp đến Ví, vì vậy hiện tại chúng tôi có dịch vụ trên bảng cân đối kế toán của mình. Hiểu cái gì và nó hoạt động như thế nào - tại sao? Dịch vụ này hoạt động và chúng tôi có các tính năng sản phẩm chắc chắn cần được cải thiện.
Nó diễn ra như thế nào
Nhưng tại một thời điểm nào đó, chúng tôi phát hiện ra rằng dịch vụ ngừng thực hiện chức năng của nó, có gì đó bị hỏng - phải làm gì trong tình huống như vậy? Dịch vụ chỉ đơn giản là ngừng hoạt động. Ở tất cả. Và chúng tôi phát hiện ra điều này, thứ nhất, một cách tình cờ, và thứ hai, sáu tháng sau. Nó xảy ra. Điều duy nhất chúng tôi biết là dịch vụ sẽ được triển khai trên máy ảo nào, nguồn của nó được đặt ở đâu, v.v. Chúng tôi thực hiện một bản sao git và đi sâu vào suy nghĩ của người đã viết bài này vài năm trước, nhưng chúng tôi thấy gì? Không có Spring Boot nào quen thuộc với chúng ta, mặc dù chúng ta đã quen với mọi thứ nhưng chúng ta có một đống đầy đủ và tất cả những thứ đó. Có lẽ có Spring Framework ở đó? Nhưng không.
Người viết tất cả những điều này thật khó khăn và viết mọi thứ bằng Java thuần túy. Không có công cụ thông thường nào dành cho nhà phát triển và một ý tưởng nảy sinh: chúng ta cần viết lại tất cả những thứ này. Chúng tôi có các dịch vụ vi mô và từ mỗi máy nướng bánh mì đều có câu thông thường “Các bạn, vi dịch vụ là những gì bạn cần!” Nếu đột nhiên có sự cố xảy ra, bạn có thể bình tĩnh sử dụng bất kỳ ngôn ngữ nào và mọi thứ sẽ ổn.
Vấn đề là hiện tại chúng tôi không có khách hàng chịu trách nhiệm về dịch vụ này. Anh ta có yêu cầu kinh doanh gì, dịch vụ này nên làm gì? Và dịch vụ được tích hợp chặt chẽ vào quy trình kinh doanh của bạn.
Bây giờ hãy cho tôi biết, việc viết lại một dịch vụ mà không cần biết các yêu cầu nghiệp vụ của nó có dễ dàng không? Không rõ dịch vụ được ghi lại như thế nào; liệu có số liệu nào không. Chúng là gì, nếu có, thì càng chưa được biết đến nhiều hơn. Đồng thời, dịch vụ này chứa một số lượng lớn các lớp logic kinh doanh khó hiểu. Một cái gì đó được bao gồm trong một số loại cơ sở dữ liệu mà chúng tôi cũng chưa biết gì về nó.
Bắt đầu từ đâu?
Từ điểm hợp lý nhất - sự sẵn có của các bài kiểm tra. Thường có ít nhất một số logic được viết ở đó và bạn có thể rút ra kết luận về những gì đang xảy ra. Bây giờ TDD là mốt, nhưng chúng ta thấy rằng 5 năm trước mọi thứ gần như giống như bây giờ: hầu như không có bài kiểm tra đơn vị nào và chúng sẽ không cho chúng ta biết bất cứ điều gì. Chà, có lẽ ngoại trừ một số loại xác minh, cách một số xml được ký bằng một số chứng chỉ tùy chỉnh.
Chúng tôi không thể hiểu bất cứ điều gì từ mã, vì vậy chúng tôi đã đi xem có gì trong máy ảo. Chúng tôi đã mở nhật ký dịch vụ và tìm thấy lỗi máy khách http trong đó; chứng chỉ tự ký được nhúng trong tài nguyên ứng dụng đã bị hỏng một cách trắng trợn. Chúng tôi đã liên hệ với các nhà phân tích của mình, họ yêu cầu chứng chỉ mới, họ cấp cho chúng tôi và dịch vụ đã hoạt động trở lại. Có vẻ như đó là tất cả. Hay không? Rốt cuộc, dịch vụ này hoạt động, nó thực hiện một số chức năng mà doanh nghiệp của chúng tôi cần. Chúng tôi có những tiêu chuẩn nhất định để phát triển ứng dụng và rất có thể bạn cũng vậy. Ví dụ: không lưu trữ nhật ký trên nút trong một thư mục mà hãy lưu trữ chúng trong một số loại lưu trữ, chẳng hạn như đàn hồi và xem chúng trong Kibana. Bạn cũng có thể nhớ các số liệu vàng. Đó là, tải trọng của dịch vụ, số lượng yêu cầu dịch vụ, anh ta còn sống hay không, HealthCheck của anh ta diễn ra như thế nào. Ít nhất, những số liệu này sẽ giúp bạn biết khi nào nó có thể ngừng hoạt động với lương tâm trong sáng và bị lãng quên như một cơn ác mộng.
Phải làm gì
Do đó, chúng tôi thêm một dịch vụ cũ như vậy vào bảng và sau đó chúng tôi tìm kiếm tình nguyện viên trong số các nhà phát triển, những người sẽ chăm sóc dịch vụ và sắp xếp nó theo thứ tự: họ sẽ viết ít nhất một số thông tin về dịch vụ, thêm liên kết vào bảng thông tin trong grafana, để tập hợp các tác vụ và hiểu cách Triển khai ứng dụng, không tải tệp lên theo cách thủ công bằng ftp.
Điều quan trọng là tất cả hoạt động tình nguyện hữu ích này sẽ kéo dài bao lâu? Ví dụ: một lần chạy nước rút dành cho một nhà phát triển ít nhiều kinh nghiệm khi mắc nợ kỹ thuật 20%. Mất bao lâu để hiểu tất cả logic thâm căn cố đế của việc giao tiếp với một hệ thống trạng thái nhất định và áp dụng nó vào các công nghệ mới hơn? Tôi không thể đảm bảo điều này, có thể là một hoặc hai tháng công việc của nhóm. Tôi nói điều này từ kinh nghiệm tích hợp hiện tại với một số dịch vụ mới.
Đồng thời, không có sự giải phóng giá trị doanh nghiệp. Ở tất cả. Việc thuê một dịch vụ để được hỗ trợ và dành một chút thời gian cho nó là điều bình thường. Nhưng sau những bước nhảy vọt tiêu chuẩn của chúng tôi với dịch vụ, chúng tôi đã thêm nó vào bảng, thêm thông tin về nó và có lẽ một ngày nào đó sẽ viết lại nó. Nhưng bây giờ nó đáp ứng các tiêu chuẩn dịch vụ của chúng tôi.
Do đó, tôi muốn đưa ra một kế hoạch về những việc cần làm với các dịch vụ Legacy.
Viết lại di sản từ đầu là một ý tưởng tồi
Nghiêm túc mà nói, bạn thậm chí không cần phải suy nghĩ về nó. Rõ ràng là tôi muốn, có một số lợi ích nhưng thường thì không ai cần, kể cả chính bạn.
Cẩm nang
Tìm hiểu mã nguồn của các ứng dụng của bạn, tạo một cuốn sách tham khảo sẽ cho biết nó ở đâu và hoạt động như thế nào, nhập mô tả về dự án vào đó (readme.md có điều kiện) để nhanh chóng hiểu vị trí của nhật ký và số liệu. Nhà phát triển sẽ giải quyết vấn đề này sau bạn sẽ chỉ nói lời cảm ơn.
Hiểu tên miền
Nếu bạn sở hữu một tên miền, hãy cố gắng giữ nhịp tim của bạn. Nghe có vẻ tầm thường, đúng vậy, nhưng không phải ai cũng đảm bảo rằng các dịch vụ đều nằm trong một khóa duy nhất. Nhưng làm việc theo một tiêu chuẩn thực sự dễ dàng hơn nhiều.
Chỉ những người dùng đã đăng ký mới có thể tham gia khảo sát. , xin vui lòng.
Bạn làm gì với di sản của mình?
-
31.5%Tôi đang viết lại từ đầu, nó đúng hơn 12
-
52.6%Gần giống như bạn20
-
10.5%Chúng tôi không có di sản, chúng tôi tuyệt vời4
-
5.2%Tôi sẽ viết trong phần bình luận2
38 người dùng bình chọn. 20 người dùng bỏ phiếu trắng.
Nguồn: www.habr.com