Giám đốc Điều hành của cổng Banki.ru Andrey Nikolsky phát biểu tại hội nghị năm ngoái về các dịch vụ mồ côi: cách xác định một dịch vụ mồ côi trong cơ sở hạ tầng, tại sao các dịch vụ mồ côi lại kém, phải làm gì với chúng và phải làm gì nếu không có gì hữu ích.
Bên dưới phần cắt là phiên bản văn bản của báo cáo.
Xin chào các đồng nghiệp! Tên tôi là Andrey, tôi đứng đầu hoạt động tại Banki.ru.
Chúng tôi có những dịch vụ lớn, đây là những dịch vụ nguyên khối, có những dịch vụ theo nghĩa cổ điển hơn và có những dịch vụ rất nhỏ. Trong thuật ngữ công-nông dân của tôi, tôi nói rằng nếu dịch vụ đơn giản và nhỏ thì đó là dịch vụ vi mô, còn nếu dịch vụ không đơn giản và nhỏ thì đó chỉ là dịch vụ.
Ưu điểm của dịch vụ
Tôi sẽ nhanh chóng điểm qua những ưu điểm của dịch vụ.
Đầu tiên là mở rộng quy mô. Bạn có thể nhanh chóng làm điều gì đó trên dịch vụ và bắt đầu sản xuất. Bạn đã nhận được lưu lượng truy cập, bạn đã nhân bản dịch vụ. Bạn có nhiều lưu lượng truy cập hơn, bạn đã nhân bản nó và sống với nó. Đây là một phần thưởng tốt và về nguyên tắc, khi chúng tôi bắt đầu, nó được coi là điều quan trọng nhất đối với chúng tôi, tại sao chúng tôi lại làm tất cả những điều này.
Thứ hai, phát triển biệt lập, khi bạn có một số nhóm phát triển, nhiều nhà phát triển khác nhau trong mỗi nhóm và mỗi nhóm phát triển dịch vụ riêng của mình.
Với các đội có một sắc thái. Các nhà phát triển thì khác. Và có, ví dụ, . Lần đầu tiên tôi nhìn thấy điều này với Maxim Dorofeev. Đôi khi những người thuộc bông tuyết ở một số đội chứ không phải ở những đội khác. Điều này làm cho các dịch vụ khác nhau được sử dụng trong toàn công ty có phần không đồng đều.
Hãy nhìn vào bức tranh: đây là một nhà phát triển giỏi, anh ấy có bàn tay to, anh ấy có thể làm được rất nhiều. Vấn đề chính là những bàn tay này đến từ đâu.
Các dịch vụ cho phép sử dụng các ngôn ngữ lập trình khác nhau phù hợp hơn cho các tác vụ khác nhau. Một số dịch vụ bằng Go, một số bằng Erlang, một số bằng Ruby, một số bằng PHP, một số bằng Python. Nói chung, bạn có thể mở rộng rất rộng rãi. Ở đây cũng có những sắc thái.
Kiến trúc hướng dịch vụ chủ yếu dành cho các nhà phát triển. Nghĩa là, nếu bạn không có tính năng tự động hóa, không có quy trình triển khai, nếu bạn định cấu hình thủ công, cấu hình của bạn có thể thay đổi từ phiên bản dịch vụ này sang phiên bản dịch vụ khác và bạn phải đến đó để làm điều gì đó, thì bạn sẽ gặp rắc rối.
Ví dụ: bạn có 20 dịch vụ và bạn cần triển khai bằng tay, bạn có 20 bảng điều khiển và bạn đồng thời nhấn “enter” như một ninja. Không được tốt lắm.
Nếu bạn có một dịch vụ sau khi thử nghiệm (tất nhiên là nếu có thử nghiệm) và bạn vẫn cần hoàn thành nó bằng một tệp để nó hoạt động trong quá trình sản xuất, thì tôi cũng có một tin xấu cho bạn.
Nếu bạn dựa vào các dịch vụ cụ thể của Amazon và làm việc ở Nga, thì hai tháng trước bạn cũng có “Mọi thứ xung quanh đều cháy, tôi ổn, mọi thứ đều ổn”.
Chúng tôi sử dụng Ansible để tự động hóa việc triển khai, Puppet để hội tụ, Bamboo để tự động hóa việc triển khai và Confluence để mô tả tất cả bằng cách nào đó.
Tôi sẽ không đi sâu vào vấn đề này một cách chi tiết vì báo cáo thiên về thực hành tương tác chứ không phải về việc triển khai kỹ thuật.
Ví dụ: chúng tôi gặp sự cố khi Puppet trên máy chủ hoạt động với Ruby 2, nhưng một số ứng dụng được viết cho Ruby 1.8 và chúng không hoạt động cùng nhau. Có gì đó không ổn ở đó. Và khi bạn cần chạy nhiều phiên bản Ruby trên một máy, bạn thường bắt đầu gặp vấn đề.
Ví dụ: chúng tôi cung cấp cho mỗi nhà phát triển một nền tảng trên đó có gần như mọi thứ chúng tôi có, tất cả các dịch vụ có thể được phát triển, để anh ấy có một môi trường biệt lập, anh ấy có thể phá vỡ nó và xây dựng nó theo ý muốn.
Điều đó xảy ra là bạn cần một số gói được biên dịch đặc biệt để hỗ trợ một cái gì đó ở đó. Nó khá khó khăn. Tôi đã nghe một báo cáo trong đó hình ảnh Docker nặng 45 GB. Tất nhiên, trong Linux, nó đơn giản hơn, mọi thứ ở đó đều nhỏ hơn, nhưng vẫn không có đủ dung lượng.
Chà, có những sự phụ thuộc xung đột nhau, khi một phần của dự án phụ thuộc vào thư viện của một phiên bản, phần khác của dự án phụ thuộc vào phiên bản khác và các thư viện hoàn toàn không được cài đặt cùng nhau.
Chúng tôi có các trang web và dịch vụ bằng PHP 5.6, chúng tôi rất xấu hổ về chúng, nhưng chúng tôi có thể làm gì? Đây là một trang web của chúng tôi. Có các trang web và dịch vụ trên PHP 7, còn nhiều trang web và dịch vụ khác nữa, chúng tôi không xấu hổ về chúng. Và mỗi nhà phát triển đều có cơ sở riêng của mình, nơi anh ấy vui vẻ nhìn thấy.
Nếu bạn viết cho một công ty bằng một ngôn ngữ thì ba máy ảo cho mỗi nhà phát triển nghe có vẻ bình thường. Nếu bạn có các ngôn ngữ lập trình khác nhau thì tình hình sẽ trở nên tồi tệ hơn.
Bạn có các trang web và dịch vụ trên này, trên này, sau đó là một trang khác dành cho Go, một trang dành cho Ruby và một số Redis khác ở bên cạnh. Kết quả là, tất cả những điều này biến thành một lĩnh vực rộng lớn để hỗ trợ và một số trong đó luôn có thể bị phá vỡ.
Do đó, chúng tôi đã thay thế lợi ích của ngôn ngữ lập trình bằng việc sử dụng các khung công tác khác nhau, vì các khung công tác PHP khá khác nhau, chúng có các khả năng khác nhau, cộng đồng khác nhau và hỗ trợ khác nhau. Và bạn có thể viết một dịch vụ để bạn đã có sẵn thứ gì đó cho nó.
Mỗi dịch vụ đều có đội ngũ riêng
Ưu điểm chính của chúng tôi được hình thành qua nhiều năm là mỗi dịch vụ đều có đội ngũ riêng. Điều này thuận tiện cho một dự án lớn, bạn có thể tiết kiệm thời gian về tài liệu, người quản lý biết rõ dự án của họ.
Bạn có thể dễ dàng gửi nhiệm vụ từ bộ phận hỗ trợ. Ví dụ, dịch vụ bảo hiểm bị hỏng. Và ngay lập tức đội giải quyết vấn đề bảo hiểm sẽ tiến hành khắc phục.
Các tính năng mới đang được tạo ra một cách nhanh chóng, bởi vì khi bạn có một dịch vụ nguyên tử, bạn có thể nhanh chóng đưa thứ gì đó vào đó.
Và khi bạn phá vỡ dịch vụ của mình và điều này chắc chắn xảy ra, bạn không ảnh hưởng đến dịch vụ của người khác và các nhà phát triển có chút thành phần từ các nhóm khác sẽ không chạy đến chỗ bạn và nói: “Ồ, đừng làm vậy”.
Như mọi khi, có những sắc thái. Chúng tôi có những đội ổn định, những người quản lý gắn bó với đội. Có giấy tờ rõ ràng, quản lý giám sát chặt chẽ mọi việc. Mỗi nhóm có người quản lý có một số dịch vụ và có một điểm năng lực cụ thể.
Nếu các đội đang lơ lửng (đôi khi chúng tôi cũng sử dụng phương pháp này), có một phương pháp hay được gọi là “bản đồ sao”.
Bạn có một danh sách các dịch vụ và con người. Dấu hoa thị có nghĩa là người đó là chuyên gia trong dịch vụ này, một cuốn sách có nghĩa là người đó đang nghiên cứu dịch vụ này. Nhiệm vụ của người đó là đổi cuốn sách lấy một dấu hoa thị. Và nếu không có gì được viết trước dịch vụ, thì vấn đề sẽ bắt đầu, điều mà tôi sẽ nói thêm.
Các dịch vụ mồ côi xuất hiện như thế nào?
Vấn đề đầu tiên, cách đầu tiên để có được dịch vụ mồ côi trong cơ sở hạ tầng của bạn là sa thải mọi người. Có ai đã từng thấy một doanh nghiệp đáp ứng được thời hạn trước khi nhiệm vụ được đánh giá chưa? Đôi khi xảy ra trường hợp thời hạn quá gấp rút và đơn giản là không có đủ thời gian để chuẩn bị tài liệu. “Chúng tôi cần chuyển giao dịch vụ cho bộ phận sản xuất, sau đó chúng tôi sẽ bổ sung thêm.”
Nếu nhóm nhỏ, sẽ xảy ra trường hợp có một nhà phát triển viết mọi thứ, những người còn lại phụ trách. “Tôi đã viết kiến trúc cơ bản, hãy thêm các giao diện.” Sau đó, tại một thời điểm nào đó, người quản lý sẽ rời đi. Và trong giai đoạn này, khi người quản lý đã rời đi và người quản lý mới vẫn chưa được bổ nhiệm, các nhà phát triển sẽ tự quyết định dịch vụ sẽ đi đâu và điều gì đang xảy ra ở đó. Và như chúng ta đã biết (hãy quay lại một vài slide), trong một số đội có người bông tuyết, đôi khi là trưởng nhóm bông tuyết. Sau đó anh ấy bỏ việc và chúng tôi nhận được một dịch vụ mồ côi.
Đồng thời, các nhiệm vụ từ hỗ trợ và kinh doanh không biến mất; chúng bị tồn đọng. Nếu có bất kỳ lỗi kiến trúc nào trong quá trình phát triển dịch vụ, chúng cũng sẽ bị tồn đọng. Dịch vụ đang dần xấu đi.
Làm thế nào để xác định một đứa trẻ mồ côi?
Danh sách này mô tả tốt tình hình. Ai đã học được điều gì về cơ sở hạ tầng của họ?
Về các cách giải quyết được ghi lại: có một dịch vụ và nói chung là nó hoạt động, nó có một hướng dẫn dài hai trang về cách làm việc với nó, nhưng không ai biết nó hoạt động như thế nào bên trong.
Hoặc, ví dụ, có một số loại công cụ rút gọn liên kết. Ví dụ: chúng tôi hiện có ba công cụ rút ngắn liên kết được sử dụng cho các mục đích khác nhau trong các dịch vụ khác nhau. Đây chỉ là những hậu quả.
Bây giờ tôi sẽ là đội trưởng của điều hiển nhiên. Nên làm gì? Đầu tiên, chúng ta cần chuyển dịch vụ cho người quản lý khác, nhóm khác. Nếu trưởng nhóm của bạn vẫn chưa nghỉ việc, thì trong nhóm khác này, khi bạn hiểu rằng dịch vụ này giống như một đứa trẻ mồ côi, bạn cần phải có một người hiểu ít nhất đôi điều về nó.
Điều chính: bạn phải có thủ tục chuyển giao được viết bằng máu. Trong trường hợp của chúng tôi, tôi thường theo dõi điều này vì tôi cần tất cả để hoạt động. Các nhà quản lý cần nó được chuyển giao nhanh chóng và những gì xảy ra sau đó không còn quá quan trọng đối với họ nữa.
Cách tiếp theo để tạo ra trẻ mồ côi là “Chúng tôi sẽ thuê ngoài, sẽ nhanh hơn và sau đó chúng tôi sẽ giao lại cho nhóm”. Rõ ràng là mọi người đều có một số kế hoạch trong đội, một lượt. Thường thì khách hàng doanh nghiệp nghĩ rằng người đăng việc sẽ làm những việc tương tự như bộ phận kỹ thuật mà công ty có. Mặc dù động lực của họ là khác nhau. Có những giải pháp công nghệ lạ, giải pháp thuật toán lạ trong outsourcing.
Ví dụ: chúng tôi có một dịch vụ có Sphinx ở nhiều nơi không ngờ tới. Sau này tôi sẽ kể cho bạn nghe tôi phải làm gì.
Người đăng việc có khuôn khổ tự viết. Đây chỉ là PHP đơn giản với tính năng sao chép-dán từ một dự án trước đó, nơi bạn có thể tìm thấy tất cả mọi thứ. Các tập lệnh triển khai là một nhược điểm lớn khi bạn cần sử dụng một số tập lệnh Bash phức tạp để thay đổi một số dòng trong một số tệp và các tập lệnh triển khai này được gọi bởi một số tập lệnh thứ ba. Kết quả là bạn thay đổi hệ thống triển khai, chọn thứ khác, nhưng dịch vụ của bạn không hoạt động. Bởi vì ở đó cần phải đặt thêm 8 liên kết giữa các thư mục khác nhau. Hoặc xảy ra trường hợp một nghìn bản ghi hoạt động nhưng một trăm nghìn bản ghi không còn hoạt động.
Tôi sẽ tiếp tục làm đội trưởng. Việc chấp nhận sử dụng dịch vụ thuê ngoài là một thủ tục bắt buộc. Có ai đã từng có một dịch vụ thuê ngoài đến và không được chấp nhận ở bất cứ đâu chưa? Tất nhiên, điều này không phổ biến như một dịch vụ mồ côi, nhưng vẫn vậy.
Dịch vụ cần được kiểm tra, dịch vụ cần được xem xét, mật khẩu cần được thay đổi. Chúng tôi gặp trường hợp khi họ cung cấp dịch vụ cho chúng tôi, có một bảng quản trị “if login == 'admin' && pass == 'admin'...", nó được viết ngay trong mã. Chúng ta ngồi và suy nghĩ, và mọi người viết điều này vào năm 2018?
Kiểm tra dung lượng lưu trữ cũng là một việc cần thiết. Bạn cần xem điều gì sẽ xảy ra trên hàng trăm nghìn bản ghi, ngay cả trước khi bạn đưa dịch vụ này vào sản xuất ở đâu đó.
Không có gì phải xấu hổ khi gửi một dịch vụ để cải thiện. Khi bạn nói: “Chúng tôi sẽ không nhận dịch vụ này, chúng tôi có 20 nhiệm vụ, làm chúng thì chúng tôi sẽ nhận”, điều này là bình thường. Lương tâm của bạn không nên bị tổn thương bởi việc bạn đang bổ nhiệm một người quản lý hoặc doanh nghiệp đang lãng phí tiền bạc. Khi đó doanh nghiệp sẽ chi tiêu nhiều hơn.
Chúng tôi đã gặp trường hợp khi quyết định thuê ngoài một dự án thí điểm.
Nó được giao đúng thời hạn và đây là tiêu chí chất lượng duy nhất. Đó là lý do tại sao chúng tôi thực hiện một dự án thí điểm khác, thậm chí còn không thực sự là một dự án thí điểm nữa. Các dịch vụ này đã được chấp nhận và thông qua các biện pháp hành chính, họ nói, đây là mã của bạn, đây là nhóm, đây là người quản lý của bạn. Các dịch vụ thực sự đã bắt đầu tạo ra lợi nhuận. Đồng thời, trên thực tế, họ vẫn là những đứa trẻ mồ côi, không ai hiểu cách họ làm việc, và những người quản lý cố gắng hết sức để từ chối nhiệm vụ của họ.
Có một khái niệm tuyệt vời khác - phát triển du kích. Khi một bộ phận nào đó, thường là bộ phận tiếp thị, muốn kiểm tra một giả thuyết và đặt hàng thuê ngoài toàn bộ dịch vụ. Xe cộ bắt đầu đổ vào, họ đóng hồ sơ, ký hồ sơ với nhà thầu, đi vào hoạt động và nói: “Các bạn ơi, ở đây chúng tôi có dịch vụ, có xe cộ rồi, nó mang lại tiền cho chúng tôi, chấp nhận đi”. Chúng tôi đã nói, "Oppa, sao có thể như vậy được."
Và một cách khác để có được dịch vụ mồ côi: khi một đội nào đó đột nhiên trở nên quá tải, ban quản lý nói: “Hãy chuyển dịch vụ của đội này sang đội khác, nó có tải nhỏ hơn”. Và sau đó chúng tôi sẽ chuyển nó sang đội thứ ba và thay đổi người quản lý. Và cuối cùng chúng ta lại có một đứa trẻ mồ côi.
Vấn đề với trẻ mồ côi là gì?
Ai mà không biết, đây chính là chiến hạm Wasa được nuôi dưỡng ở Thụy Điển, nổi tiếng vì bị chìm 5 phút sau khi hạ thủy. Và nhân tiện, Vua Thụy Điển đã không xử tử bất cứ ai vì việc này. Nó được chế tạo bởi hai thế hệ kỹ sư không biết cách đóng những con tàu như vậy. Hiệu ứng tự nhiên.
Nhân tiện, con tàu có thể bị chìm theo cách tồi tệ hơn nhiều, chẳng hạn như khi nhà vua đang cưỡi nó đi đâu đó trong một cơn bão. Và thế là anh ta chết đuối ngay, theo Agile thì thất bại sớm là tốt.
Nếu chúng ta thất bại sớm thì thường không có vấn đề gì. Ví dụ, trong quá trình chấp nhận nó đã được gửi đi để sửa đổi. Nhưng nếu chúng tôi đã thất bại trong quá trình sản xuất, khi tiền được đầu tư, thì có thể sẽ có vấn đề. Hậu quả, như chúng được gọi trong kinh doanh.
Tại sao dịch vụ mồ côi lại nguy hiểm:
- Dịch vụ có thể bị hỏng đột ngột.
- Dịch vụ sửa chữa rất lâu hoặc không được sửa chữa gì cả.
- Vấn đề an toàn.
- Các vấn đề với cải tiến và cập nhật.
- Nếu một dịch vụ quan trọng bị hỏng, danh tiếng của công ty sẽ bị ảnh hưởng.
Làm gì với các dịch vụ mồ côi?
Tôi sẽ lặp lại những gì cần làm một lần nữa. Đầu tiên phải có tài liệu. 7 năm làm việc tại Banki.ru đã dạy tôi rằng những người thử nghiệm không nên nghe theo lời của các nhà phát triển và các hoạt động không nên nghe theo lời của tất cả mọi người. Chúng ta cần kiểm tra.
Thứ hai, cần phải viết sơ đồ tương tác, vì sẽ xảy ra trường hợp các dịch vụ không được đón nhận nhiều sẽ chứa những phần phụ thuộc mà không ai nói đến. Ví dụ: các nhà phát triển đã cài đặt dịch vụ trên khóa của họ cho một số Yandex.Maps hoặc Dadata. Bạn đã hết giới hạn miễn phí, mọi thứ đều hỏng và bạn không biết chuyện gì đã xảy ra. Tất cả những thứ cào như vậy phải được mô tả: dịch vụ sử dụng Dadata, SMS, cái gì khác.
Thứ ba, xử lý nợ kỹ thuật. Khi bạn chống nạng hoặc chấp nhận một dịch vụ và nói rằng cần phải làm điều gì đó, bạn cần đảm bảo rằng việc đó đã được thực hiện. Bởi vì khi đó có thể cái lỗ nhỏ đó không nhỏ đến thế và bạn sẽ rơi qua đó.
Với nhiệm vụ kiến trúc, chúng tôi đã có câu chuyện về Sphinx. Một trong những dịch vụ đã sử dụng Sphinx để nhập danh sách. Chỉ là một danh sách được đánh số trang, nhưng nó được lập chỉ mục lại hàng đêm. Nó được tập hợp từ hai mục lục: một mục lớn được lập mục lục mỗi đêm và cũng có một mục mục nhỏ được gắn chặt vào đó. Mỗi ngày, với xác suất 50% có đánh bom hay không, chỉ số bị sập trong quá trình tính toán và tin tức của chúng tôi ngừng cập nhật trên trang chính. Lúc đầu phải mất 5 phút để lập chỉ mục lại, sau đó chỉ số tăng lên và có thời điểm bắt đầu mất 40 phút để lập chỉ mục lại. Khi chúng tôi cắt phần này ra, chúng tôi thở phào nhẹ nhõm vì rõ ràng là một thời gian nữa sẽ trôi qua và chỉ mục của chúng tôi sẽ được lập chỉ mục lại toàn thời gian. Đây sẽ là một sự thất bại đối với cổng thông tin của chúng tôi, không có tin tức nào trong tám giờ - thế là xong, hoạt động kinh doanh đã dừng lại.
Kế hoạch làm việc với một dịch vụ mồ côi
Trên thực tế, điều này rất khó thực hiện vì devops chủ yếu là giao tiếp. Bạn muốn có mối quan hệ tốt với đồng nghiệp của mình và khi bạn áp dụng các quy định vào đầu đồng nghiệp và quản lý của mình, họ có thể có cảm xúc trái ngược với những người làm điều này.
Ngoài tất cả những điểm này, còn có một điều quan trọng khác: những người cụ thể phải chịu trách nhiệm về từng dịch vụ cụ thể, từng phần cụ thể của quy trình triển khai. Khi không có người và bạn phải thu hút một số người khác nghiên cứu toàn bộ vấn đề này thì điều đó trở nên khó khăn.
Nếu tất cả những điều này không giúp ích được gì và dịch vụ mồ côi của bạn vẫn là một đứa trẻ mồ côi, không ai muốn tiếp nhận nó, tài liệu không được viết, nhóm được gọi vào dịch vụ này từ chối làm bất cứ điều gì, có một cách đơn giản - làm lại mọi thứ .
Nghĩa là, bạn lấy lại các yêu cầu đối với dịch vụ và viết một dịch vụ mới, tốt hơn, trên nền tảng tốt hơn, không có giải pháp công nghệ lạ. Và bạn di chuyển đến nó trong trận chiến.
Chúng tôi đã gặp tình huống khi sử dụng một dịch vụ trên Yii 1 và nhận ra rằng chúng tôi không thể phát triển dịch vụ đó thêm nữa vì chúng tôi đã hết nhà phát triển có thể viết tốt trên Yii 1. Tất cả các nhà phát triển đều viết tốt trên Symfony XNUMX. Phải làm gì? Chúng tôi đã phân bổ thời gian, phân bổ một nhóm, phân bổ một người quản lý, viết lại dự án và chuyển lưu lượng truy cập sang dự án đó một cách suôn sẻ.
Sau này, dịch vụ cũ có thể bị xóa. Đây là quy trình yêu thích của tôi, khi bạn cần lấy và xóa một số dịch vụ khỏi hệ thống quản lý cấu hình, sau đó xem xét và thấy rằng tất cả ô tô đang được sản xuất đã bị vô hiệu hóa, để các nhà phát triển không còn dấu vết nào. Kho lưu trữ vẫn còn trong Git.
Đây là tất cả những gì tôi muốn nói, tôi sẵn sàng thảo luận, chủ đề là holivar, nhiều người đã bơi trong đó.
Các slide nói rằng bạn đã thống nhất các ngôn ngữ. Một ví dụ là việc thay đổi kích thước hình ảnh. Có thực sự cần thiết phải giới hạn nghiêm ngặt nó trong một ngôn ngữ? Bởi vì việc thay đổi kích thước hình ảnh trong PHP thực sự có thể được thực hiện ở Golang.
Trên thực tế, nó là tùy chọn, giống như tất cả các phương pháp thực hành khác. Có lẽ, trong một số trường hợp, nó thậm chí còn là điều không mong muốn. Nhưng bạn cần hiểu rằng nếu bạn có bộ phận kỹ thuật trong một công ty gồm 50 người, thì 45 người trong số họ là chuyên gia PHP, 3 người khác là nhà phát triển biết Python, Ansible, Puppet và những thứ tương tự, và chỉ một trong số họ viết bằng một số kiến thức. loại ngôn ngữ nào đó của dịch vụ thay đổi kích thước hình ảnh Go, sau đó khi nó rời đi, chuyên môn sẽ đi cùng với nó. Đồng thời, bạn sẽ cần tìm kiếm một nhà phát triển dành riêng cho thị trường biết ngôn ngữ này, đặc biệt nếu nó hiếm. Nghĩa là, từ quan điểm tổ chức, đây là vấn đề. Từ quan điểm của nhà phát triển, bạn sẽ không chỉ cần sao chép một số cẩm nang làm sẵn mà bạn sử dụng để triển khai các dịch vụ mà còn phải viết lại tất cả chúng.
Chúng tôi hiện đang xây dựng một dịch vụ trên Node.js và đây sẽ chỉ là một nền tảng gần đó cho mỗi nhà phát triển có ngôn ngữ riêng. Nhưng chúng tôi đã ngồi và nghĩ rằng trò chơi này thật đáng giá. Tức là đây là một câu hỏi để bạn ngồi suy nghĩ.
Bạn giám sát dịch vụ của mình như thế nào? Bạn thu thập và theo dõi nhật ký bằng cách nào?
Chúng tôi thu thập nhật ký trong Elaticsearch và đưa chúng vào Kibana, tùy thuộc vào việc đó là môi trường sản xuất hay thử nghiệm, các trình thu thập khác nhau sẽ được sử dụng ở đó. Ở đâu đó Lumberjack, ở đâu đó khác, tôi không nhớ. Và vẫn còn một số nơi trong một số dịch vụ nhất định nơi chúng tôi cài đặt Telegraf và quay riêng ở một nơi khác.
Làm thế nào để sống chung với Puppet và Ansible trong cùng một môi trường?
Trên thực tế, hiện tại chúng ta có hai môi trường, một là Puppet, hai là Ansible. Chúng tôi đang làm việc để lai chúng. Ansible là một framework tốt cho thiết lập ban đầu, Puppet là một framework tồi cho thiết lập ban đầu vì nó yêu cầu thực hành trực tiếp trên nền tảng và Puppet đảm bảo hội tụ cấu hình. Điều này có nghĩa là nền tảng này tự duy trì ở trạng thái cập nhật và để máy được đồng hóa luôn cập nhật, bạn cần chạy playbook trên đó mọi lúc với tần suất nhất định. Đó là sự khác biệt.
Làm thế nào để bạn duy trì khả năng tương thích? Bạn có cấu hình trong cả Ansible và Puppet không?
Đây là nỗi đau lớn của chúng tôi, chúng tôi duy trì khả năng tương thích với đôi tay của mình và suy nghĩ về cách tiếp tục từ tất cả những điều này ở đâu đó ngay bây giờ. Hóa ra Puppet tung ra các gói và duy trì một số liên kết ở đó, và Ansible chẳng hạn, tung ra mã và điều chỉnh các cấu hình ứng dụng mới nhất ở đó.
Bài thuyết trình nói về các phiên bản khác nhau của Ruby. Những giải pháp?
Chúng tôi đã gặp phải điều này ở một nơi và chúng tôi phải luôn ghi nhớ nó trong đầu. Chúng tôi chỉ cần tắt phần chạy trên Ruby không tương thích với các ứng dụng và giữ nó riêng biệt.
Hội nghị năm nay sẽ diễn ra vào ngày 7 tháng 11 tại Technopolis. Chúng tôi đang chấp nhận đơn đăng ký báo cáo cho đến ngày XNUMX tháng XNUMX. chúng tôi nếu bạn muốn nói chuyện.
Đăng ký cho người tham gia đã mở, hãy tham gia cùng chúng tôi!
Nguồn: www.habr.com