Sự trùng hợp là ngẫu nhiên, và thực sự nó đã xảy ra ở một hành tinh khác...
Tôi muốn chia sẻ ba câu chuyện thành công và thất bại về cách một nhà phát triển phụ trợ làm việc trong nhóm có quản trị viên.
Lịch sử đầu tiên.
Web studio, số lượng nhân viên có thể đếm được bằng một bàn tay. Hôm nay bạn là nhà thiết kế bố cục, ngày mai bạn là người hỗ trợ, ngày kia bạn là quản trị viên. Một mặt, bạn có thể có được kinh nghiệm to lớn. Mặt khác, còn thiếu năng lực ở mọi lĩnh vực. Tôi vẫn nhớ ngày đầu tiên đi làm, tôi vẫn còn xanh, sếp nói: “Mở bột trét ra,” nhưng tôi không biết đó là gì. Việc liên lạc với quản trị viên bị loại trừ vì bản thân bạn là quản trị viên Hãy xem xét những ưu và nhược điểm của tình huống này.
+ Mọi quyền lực đều nằm trong tay bạn.
+ Không cần phải cầu xin ai cho phép truy cập vào máy chủ.
+ Thời gian phản ứng nhanh theo mọi hướng.
+ Cải thiện kỹ năng tốt.
+ Có hiểu biết đầy đủ về kiến trúc sản phẩm.
- Trách nhiệm cao.
- Nguy cơ gián đoạn sản xuất.
- Làm chuyên gia giỏi mọi lĩnh vực đã khó.
Không quan tâm, hãy tiếp tục
Câu chuyện thứ hai.
Công ty lớn, dự án lớn. Có một bộ phận hành chính với 5-7 nhân viên và một số nhóm phát triển. Khi bạn đến làm việc ở một công ty như vậy, mọi quản trị viên đều nghĩ rằng bạn đến đây không phải để làm việc trên một sản phẩm mà là để phá vỡ một thứ gì đó. Cả NDA đã ký cũng như việc lựa chọn tại cuộc phỏng vấn đều không chỉ ra điều khác. Không, người đàn ông này đến đây với đôi bàn tay bẩn thỉu của mình để phá hỏng màn hôn nhau của chúng ta. Vì vậy, với một người như vậy, bạn cần giao tiếp tối thiểu, ít nhất, bạn có thể ném một nhãn dán để đáp lại. Không trả lời các câu hỏi về kiến trúc dự án. Không nên cấp quyền truy cập cho đến khi trưởng nhóm yêu cầu. Và khi anh ta yêu cầu, anh ta sẽ trả lại với ít đặc quyền hơn những gì họ yêu cầu. Hầu như mọi thông tin liên lạc với những quản trị viên như vậy đều bị lỗ đen giữa bộ phận phát triển và bộ phận hành chính hấp thụ. Không thể giải quyết vấn đề kịp thời. Nhưng bạn không thể đến trực tiếp - quản trị viên quá bận rộn 24/7. (Bạn thường xuyên làm gì?) Một số đặc điểm hiệu suất:
- Thời gian triển khai trung bình trong sản xuất là 4-5 giờ
- Thời gian triển khai tối đa trong sản xuất 9 giờ
- Đối với nhà phát triển, ứng dụng đang được sản xuất là một hộp đen, giống như chính máy chủ sản xuất. Tổng cộng có bao nhiêu?
- Chất lượng phát hành thấp, lỗi thường xuyên
- Nhà phát triển không tham gia vào quá trình phát hành
Chà, tôi đã mong đợi điều gì, tất nhiên, người mới không được phép vào sản xuất. Được rồi, khi đã có được sự kiên nhẫn, chúng ta bắt đầu chiếm được lòng tin của người khác. Nhưng không hiểu sao mọi chuyện lại không đơn giản như vậy với các admin.
Màn 1. Quản trị viên là vô hình.
Ngày phát hành, nhà phát triển và quản trị viên không liên lạc. Quản trị viên không có câu hỏi. Nhưng sau này bạn sẽ hiểu tại sao. Quản trị viên là người có nguyên tắc, không có người nhắn tin, không đưa số điện thoại của mình cho bất kỳ ai và không có hồ sơ trên mạng xã hội. Thậm chí còn không có ảnh của anh ấy ở đâu cả, trông bạn thế nào? Chúng tôi bối rối ngồi với người quản lý chịu trách nhiệm trong khoảng 15 phút, cố gắng thiết lập liên lạc với chiếc Du hành 1 này, sau đó một thông báo xuất hiện trong email công ty rằng anh ấy đã hoàn thành. Chúng ta sẽ trao đổi thư từ qua đường bưu điện phải không? Tại sao không? Thật tiện lợi phải không? Được rồi, hãy bình tĩnh lại nào. Quá trình này đã được tiến hành, không có đường quay lại. Đọc lại tin nhắn. "Tôi xong rồi". Bạn đã làm xong việc gì? Ở đâu? Tôi nên tìm bạn ở đâu? Ở đây bạn hiểu tại sao 4 giờ để phát hành là bình thường. Chúng tôi gặp phải một cú sốc trong quá trình phát triển, nhưng chúng tôi đã hoàn thành việc phát hành. Không còn chút ham muốn giải thoát nào nữa.
Màn 2. Không phải phiên bản đó.
Bản phát hành tiếp theo. Sau khi tích lũy được kinh nghiệm, chúng tôi bắt đầu tạo danh sách các phần mềm và thư viện cần thiết cho máy chủ dành cho quản trị viên, chỉ ra phiên bản cho một số phần mềm. Như mọi khi, chúng tôi nhận được tín hiệu vô tuyến yếu cho biết quản trị viên đã hoàn thành việc gì đó ở đó. Quá trình kiểm tra hồi quy bắt đầu và quá trình này mất khoảng một giờ. Mọi thứ dường như đang hoạt động nhưng có một lỗi nghiêm trọng. Chức năng quan trọng không hoạt động. Vài giờ tiếp theo là khiêu vũ với trống lục lạc, bói toán trên bã cà phê và xem xét chi tiết từng đoạn mã. Quản trị viên nói rằng anh ấy đã làm mọi thứ. Ứng dụng được viết bởi các nhà phát triển quanh co không hoạt động, nhưng máy chủ vẫn hoạt động. Có câu hỏi nào cho anh ấy không? Vào cuối một giờ, chúng tôi yêu cầu quản trị viên gửi phiên bản của thư viện trên máy chủ sản xuất vào cuộc trò chuyện và chơi lô tô - đó không phải là phiên bản chúng tôi cần. Chúng tôi yêu cầu quản trị viên cài đặt phiên bản được yêu cầu, nhưng đáp lại, chúng tôi nhận được rằng anh ta không thể thực hiện việc này do không có phiên bản này trong trình quản lý gói hệ điều hành. Ở đây, từ sâu trong trí nhớ của mình, người quản lý nhớ ra rằng một quản trị viên khác đã giải quyết vấn đề này bằng cách lắp ráp phiên bản cần thiết bằng tay. Nhưng không, chúng tôi sẽ không làm điều này. Quy định cấm. Karl, chúng ta đã ngồi đây được vài giờ rồi, thời hạn là bao nhiêu?! Chúng tôi nhận được một cú sốc khác và bằng cách nào đó kết thúc việc phát hành.
Màn 3, ngắn
Yêu cầu khẩn cấp, chức năng chính không hoạt động đối với một trong những người dùng đang sản xuất. Chúng tôi dành một vài giờ để tìm hiểu và kiểm tra. Trong môi trường phát triển, mọi thứ đều hoạt động. Có một sự hiểu biết rõ ràng rằng sẽ là một ý tưởng hay nếu xem xét nhật ký php-fpm. Không có hệ thống nhật ký nào như ELK hay Prometheus trong dự án vào thời điểm đó. Chúng tôi mở một vé đến bộ phận quản trị để họ cấp quyền truy cập vào nhật ký php-fpm trên máy chủ. Ở đây bạn cần hiểu rằng chúng tôi yêu cầu quyền truy cập là có lý do, bạn không nhớ về lỗ đen và quản trị viên bận rộn 24/7 sao? Nếu bạn yêu cầu họ tự xem nhật ký thì đây là một nhiệm vụ có mức độ ưu tiên “không phải trong cuộc đời này”. Vé được tạo, chúng tôi nhận được phản hồi ngay lập tức từ trưởng bộ phận hành chính: “Bạn không cần truy cập vào nhật ký sản xuất, viết mà không có lỗi.” Một bức màn.
Màn 4 và hơn thế nữa
Chúng tôi vẫn đang thu thập hàng tá vấn đề trong quá trình sản xuất, do các phiên bản thư viện khác nhau, phần mềm chưa được định cấu hình, tải máy chủ chưa được chuẩn bị và các vấn đề khác. Tất nhiên, cũng có lỗi code, chúng tôi sẽ không đổ lỗi cho quản trị viên về mọi tội lỗi, chúng tôi sẽ chỉ đề cập thêm một thao tác điển hình nữa cho dự án đó. Chúng tôi có khá nhiều chương trình chạy nền được khởi chạy thông qua trình giám sát và một số tập lệnh phải được thêm vào cron. Đôi khi những công nhân này ngừng làm việc. Tải trên máy chủ xếp hàng tăng với tốc độ cực nhanh và người dùng buồn bã nhìn vào trình tải quay. Để nhanh chóng khắc phục những công nhân như vậy, chỉ cần khởi động lại chúng là đủ, nhưng một lần nữa, chỉ quản trị viên mới có thể thực hiện việc này. Trong khi một hoạt động cơ bản như vậy đang được thực hiện, có thể phải mất cả ngày. Tất nhiên, ở đây cần lưu ý rằng các lập trình viên quanh co nên viết công nhân để họ không gặp sự cố, nhưng khi họ gặp sự cố, sẽ rất thú vị nếu hiểu tại sao, điều này đôi khi không thể thực hiện được do không có khả năng tiếp cận sản xuất, tất nhiên, và hậu quả là thiếu nhật ký từ nhà phát triển.
Sự biến hình.
Chịu đựng tất cả những điều này trong một thời gian khá dài, cùng với nhóm, chúng tôi bắt đầu đi theo hướng có lợi hơn cho mình. Tóm lại, chúng ta đã gặp phải những vấn đề gì?
- Thiếu sự giao tiếp chất lượng giữa các nhà phát triển và bộ phận quản trị
- Hóa ra các quản trị viên (!), hoàn toàn không hiểu ứng dụng được cấu trúc như thế nào, nó có những phụ thuộc gì và nó hoạt động như thế nào.
- Các nhà phát triển không hiểu môi trường sản xuất hoạt động như thế nào và kết quả là không thể phản ứng một cách hiệu quả với các vấn đề.
- Quá trình triển khai mất quá nhiều thời gian.
- Các bản phát hành không ổn định
Chúng ta đã làm gì?
Đối với mỗi bản phát hành, một danh sách Ghi chú phát hành đã được tạo, trong đó bao gồm danh sách công việc cần được thực hiện trên máy chủ để bản phát hành tiếp theo hoạt động. Danh sách bao gồm một số phần, công việc phải được thực hiện bởi quản trị viên, người chịu trách nhiệm phát hành và nhà phát triển. Các nhà phát triển đã nhận được quyền truy cập không cần root vào tất cả các máy chủ sản xuất, điều này giúp tăng tốc độ phát triển nói chung và giải quyết vấn đề nói riêng. Các nhà phát triển cũng hiểu rõ về cách hoạt động của quá trình sản xuất, nó được chia thành những dịch vụ nào, ở đâu và chi phí sao chép là bao nhiêu. Một số tải trọng chiến đấu đã trở nên rõ ràng hơn, điều này chắc chắn ảnh hưởng đến chất lượng của mã. Giao tiếp trong quá trình phát hành diễn ra trong cuộc trò chuyện của một trong những người nhắn tin tức thời. Thứ nhất, chúng tôi có nhật ký ghi lại mọi hành động và thứ hai, giao tiếp diễn ra trong một môi trường gần gũi hơn. Việc có lịch sử hành động đã hơn một lần cho phép nhân viên mới giải quyết vấn đề nhanh hơn. Đó là một nghịch lý, nhưng điều này thường giúp ích cho chính các quản trị viên. Tôi sẽ không cam kết nói chắc chắn, nhưng đối với tôi, có vẻ như các quản trị viên đã bắt đầu hiểu thêm về cách thức hoạt động của dự án và cách nó được viết. Đôi khi chúng tôi thậm chí còn chia sẻ một số chi tiết với nhau. Thời gian phát hành trung bình đã giảm xuống còn một giờ. Đôi khi chúng tôi hoàn thành trong 30-40 phút. Số lượng lỗi đã giảm đáng kể, nếu không muốn nói là gấp XNUMX lần. Tất nhiên, các yếu tố khác cũng ảnh hưởng đến việc giảm thời gian phát hành, chẳng hạn như autotests. Sau mỗi lần phát hành, chúng tôi bắt đầu tiến hành hồi cứu. Để cả nhóm biết được điều gì mới, điều gì đã thay đổi và điều gì đã bị xóa. Thật không may, không phải lúc nào quản trị viên cũng đến gặp họ, à, quản trị viên rất bận... Sự hài lòng trong công việc của tôi với tư cách là một nhà phát triển chắc chắn đã tăng lên. Khi bạn có thể nhanh chóng giải quyết hầu hết mọi vấn đề thuộc thẩm quyền của mình, bạn sẽ cảm thấy mình vượt trội. Sau này, tôi sẽ hiểu rằng ở một mức độ nào đó, chúng tôi đã giới thiệu một nền văn hóa sùng đạo, tất nhiên là không hoàn toàn, nhưng ngay cả sự khởi đầu của quá trình chuyển đổi đó cũng rất ấn tượng.
Chuyện ba
Khởi động. Một quản trị viên, bộ phận phát triển nhỏ. Khi đến nơi, tôi hoàn toàn là con số XNUMX, bởi vì... Tôi không có quyền truy cập bất cứ nơi nào ngoại trừ từ thư. Chúng tôi viết thư cho quản trị viên và yêu cầu quyền truy cập. Ngoài ra, có thông tin cho thấy anh ta biết về nhân viên mới và nhu cầu cấp thông tin đăng nhập/mật khẩu. Họ cấp quyền truy cập từ kho lưu trữ và VPN. Tại sao cấp quyền truy cập vào wiki, teamcity, rundesk? Những điều vô ích đối với một người được yêu cầu viết toàn bộ phần phụ trợ. Chỉ theo thời gian, chúng ta mới có quyền truy cập vào một số công cụ. Tất nhiên, sự xuất hiện đã vấp phải sự ngờ vực. Tôi đang cố gắng từ từ cảm nhận cách hoạt động của cơ sở hạ tầng của dự án thông qua các cuộc trò chuyện và câu hỏi dẫn dắt. Về cơ bản tôi không nhận ra bất cứ điều gì. Sản xuất là hộp đen giống như trước. Nhưng hơn thế nữa, ngay cả các máy chủ sân khấu được sử dụng để thử nghiệm cũng là một hộp đen. Chúng tôi không thể làm gì khác ngoài việc triển khai một nhánh từ Git ở đó. Chúng tôi cũng không thể định cấu hình ứng dụng của mình như tệp .env. Quyền truy cập cho các hoạt động như vậy không được cấp. Bạn phải cầu xin để thay đổi một dòng trong cấu hình ứng dụng của bạn trên máy chủ thử nghiệm. (Có giả thuyết cho rằng điều quan trọng là quản trị viên phải cảm thấy mình quan trọng đối với dự án; nếu họ không được yêu cầu thay đổi dòng trong cấu hình thì đơn giản là họ sẽ không cần thiết). Chà, như mọi khi, có thuận tiện không? Điều này nhanh chóng trở nên nhàm chán, sau cuộc trò chuyện trực tiếp với quản trị viên, chúng tôi phát hiện ra rằng các nhà phát triển sinh ra để viết mã xấu, về bản chất là những cá nhân kém năng lực và tốt hơn là nên tránh xa họ khỏi quá trình sản xuất. Nhưng ở đây cũng từ các máy chủ thử nghiệm, để đề phòng. Xung đột đang nhanh chóng leo thang. Không có liên lạc với quản trị viên. Tình hình trở nên trầm trọng hơn khi anh ta ở một mình. Sau đây là một hình ảnh điển hình. Giải phóng. Một số chức năng không hoạt động. Chúng tôi phải mất một thời gian dài để tìm hiểu chuyện gì đang xảy ra, nhiều ý tưởng khác nhau từ các nhà phát triển được đưa vào cuộc trò chuyện, nhưng quản trị viên trong tình huống như vậy thường cho rằng các nhà phát triển phải chịu trách nhiệm. Sau đó anh ấy viết trong cuộc trò chuyện, chờ đã, tôi đã sửa lại cho anh ấy. Khi được yêu cầu kể lại một câu chuyện kèm thông tin về vấn đề là gì, chúng ta nhận được những lời bào chữa độc hại. Giống như, đừng nhét mũi vào nơi không thuộc về nó. Các nhà phát triển phải viết mã. Tình trạng nhiều chuyển động cơ thể trong một dự án đều do một người thực hiện và chỉ có anh ta mới có quyền thực hiện các thao tác mà mọi người cần là vô cùng đáng buồn. Một người như vậy là một nút thắt khủng khiếp. Nếu các ý tưởng của Devops cố gắng giảm thời gian tiếp thị, thì những người như vậy là kẻ thù tồi tệ nhất của các ý tưởng Devops. Thật không may, bức màn đóng lại ở đây.
Tái bút Sau khi nói một chút về nhà phát triển và quản trị viên trong cuộc trò chuyện với mọi người, tôi đã gặp những người chia sẻ nỗi đau của mình. Nhưng cũng có người cho biết họ chưa từng gặp phải chuyện như thế này. Tại một hội nghị dành cho người phát triển, tôi đã hỏi Anton Isanin (Ngân hàng Alfa) cách họ giải quyết vấn đề tắc nghẽn dưới hình thức quản trị viên, anh ấy nói: “Chúng tôi đã thay thế chúng bằng các nút”. Nhân tiện với sự tham gia của anh ấy. Tôi muốn tin rằng có nhiều quản trị viên tốt hơn kẻ thù. Và vâng, hình ảnh lúc đầu là một sự tương ứng thực sự.
Nguồn: www.habr.com