Ở thời điểm hiện tại, đây gần như là vị trí đắt giá nhất trên thị trường. Sự ồn ào xung quanh các kỹ sư “DevOps” vượt quá mọi giới hạn có thể tưởng tượng được, và thậm chí còn tệ hơn với các kỹ sư DevOps cấp cao.
Tôi làm trưởng bộ phận tích hợp và tự động hóa, đoán giải mã tiếng Anh - DevOps Manager. Không chắc bản ghi tiếng Anh phản ánh hoạt động hàng ngày của chúng tôi, nhưng bản tiếng Nga trong trường hợp này chính xác hơn. Do tính chất hoạt động của tôi, việc tôi cần phỏng vấn các thành viên tương lai trong nhóm của mình là điều đương nhiên, và trong năm qua, khoảng 50 người đã lướt qua tôi, và con số tương tự đã bị loại khỏi buổi sàng lọc trước với nhân viên của tôi.
Chúng tôi vẫn đang tìm kiếm đồng nghiệp, bởi vì đằng sau cái mác DevOps có rất nhiều loại kỹ sư khác nhau đang ẩn náu.
Mọi thứ được viết dưới đây là ý kiến cá nhân của tôi, bạn không nhất thiết phải đồng ý với nó, nhưng tôi thừa nhận rằng nó sẽ mang lại chút màu sắc cho thái độ của bạn đối với chủ đề này. Bất chấp nguy cơ không được ưa chuộng, tôi công bố quan điểm của mình vì tôi tin rằng nó có chỗ đứng.
Các công ty có cách hiểu khác nhau về kỹ sư DevOps là ai và để nhanh chóng tuyển dụng nguồn lực, họ dán nhãn này cho mọi người. Tình hình khá kỳ lạ, vì các công ty sẵn sàng trả những khoản thù lao phi thực tế cho những người này, trong hầu hết các trường hợp, nhận một quản trị viên công cụ cho họ.
Vậy kỹ sư DevOps là ai?
Hãy bắt đầu với lịch sử xuất hiện của nó - Hoạt động phát triển xuất hiện như một bước nữa hướng tới việc tối ưu hóa sự tương tác trong các nhóm nhỏ nhằm tăng tốc độ sản xuất sản phẩm, như một hệ quả được mong đợi. Ý tưởng là tăng cường kiến thức cho nhóm phát triển về các quy trình và phương pháp tiếp cận trong việc quản lý môi trường sản phẩm. Nói cách khác, nhà phát triển phải hiểu và biết sản phẩm của mình hoạt động như thế nào trong những điều kiện nhất định, phải hiểu cách triển khai sản phẩm của mình, những đặc điểm nào của môi trường có thể được điều chỉnh để cải thiện hiệu suất. Vì vậy, trong một thời gian, các nhà phát triển với cách tiếp cận DevOps đã xuất hiện. Các nhà phát triển DevOps đã viết các tập lệnh xây dựng và đóng gói để đơn giản hóa các hoạt động của họ và hiệu suất của môi trường sản xuất. Tuy nhiên, sự phức tạp của kiến trúc giải pháp và sự ảnh hưởng lẫn nhau của các thành phần cơ sở hạ tầng theo thời gian bắt đầu làm giảm hiệu suất của môi trường; với mỗi lần lặp lại, cần có sự hiểu biết ngày càng sâu sắc hơn về một số thành phần nhất định, làm giảm năng suất của nhà phát triển do phải bổ sung thêm chi phí để hiểu các thành phần và hệ thống điều chỉnh cho một nhiệm vụ cụ thể. . Chi phí riêng của nhà phát triển tăng lên, giá thành sản phẩm kéo theo đó, yêu cầu đối với các nhà phát triển mới trong nhóm tăng vọt, bởi vì họ cũng cần đảm nhận trách nhiệm của “ngôi sao” phát triển và tất nhiên, các “ngôi sao” trở nên ít hơn và ít sẵn có hơn. Cũng cần lưu ý rằng, theo kinh nghiệm của tôi, rất ít nhà phát triển quan tâm đến các chi tiết cụ thể về xử lý gói bằng nhân hệ điều hành, các quy tắc định tuyến gói và các khía cạnh bảo mật máy chủ. Bước hợp lý là thu hút một quản trị viên quen thuộc với vấn đề này và giao những trách nhiệm tương tự cho anh ta, nhờ kinh nghiệm của anh ta, giúp anh ta có thể đạt được các chỉ số tương tự với chi phí thấp hơn so với chi phí phát triển “ngôi sao”. Những quản trị viên như vậy được xếp vào một nhóm và nhiệm vụ chính của anh ta là quản lý môi trường sản xuất và thử nghiệm, theo các quy tắc của một nhóm cụ thể, với các nguồn lực được phân bổ cho nhóm cụ thể này. Trên thực tế, đây là cách DevOps xuất hiện trong tâm trí của đa số.
Một phần hoặc toàn bộ, theo thời gian, những quản trị viên hệ thống này bắt đầu hiểu nhu cầu của nhóm cụ thể này trong lĩnh vực phát triển, cách giúp cuộc sống của các nhà phát triển và người thử nghiệm dễ dàng hơn, cách tung ra bản cập nhật và không phải thức qua đêm vào thứ Sáu trong văn phòng, sửa lỗi triển khai. Thời gian trôi qua, giờ đây các “ngôi sao” là những quản trị viên hệ thống hiểu rõ mong muốn của các nhà phát triển. Để giảm thiểu tác động, các tiện ích quản lý bắt đầu xuất hiện, mọi người đều nhớ đến các phương pháp cách ly cấp độ hệ điều hành cũ và đáng tin cậy, giúp giảm thiểu các yêu cầu về bảo mật, quản lý phần mạng và cấu hình máy chủ như một toàn bộ và do đó, giảm yêu cầu đối với các “ngôi sao” mới.
Một điều “tuyệt vời” đã xuất hiện - docker. Tại sao tuyệt vời? Có, chỉ vì việc tạo sự cô lập trong chroot hoặc jail, cũng như OpenVZ, đòi hỏi kiến thức không hề nhỏ về hệ điều hành, ngược lại, tiện ích này cho phép bạn chỉ cần tạo một môi trường ứng dụng biệt lập trên một máy chủ nhất định với mọi thứ cần thiết bên trong và trong tay lại tiếp tục phát triển và quản trị viên hệ thống chỉ có thể quản lý chỉ với một máy chủ, đảm bảo tính bảo mật và tính sẵn sàng cao - một sự đơn giản hóa hợp lý. Nhưng sự tiến bộ không đứng yên và các hệ thống lại ngày càng trở nên phức tạp hơn, ngày càng có nhiều thành phần, một máy chủ không còn đáp ứng được nhu cầu của hệ thống và cần phải xây dựng các cụm, chúng ta lại quay trở lại với những quản trị viên hệ thống, những người có khả năng xây dựng các hệ thống này.
Hết chu kỳ này đến chu kỳ khác, các hệ thống khác nhau xuất hiện giúp đơn giản hóa việc phát triển và/hoặc quản trị, các hệ thống điều phối xuất hiện, hệ thống này rất dễ sử dụng cho đến khi bạn cần đi chệch khỏi quy trình tiêu chuẩn. Kiến trúc microservice cũng xuất hiện với mục đích đơn giản hóa mọi thứ được mô tả ở trên - ít mối quan hệ hơn, dễ quản lý hơn. Theo kinh nghiệm của tôi, tôi không tìm thấy một kiến trúc microservice hoàn chỉnh, tôi có thể nói rằng 50 đến 50 - 50 phần trăm microservice, hộp đen, được đưa vào, được xử lý, 50 phần còn lại là một khối nguyên khối rách nát, các dịch vụ không thể hoạt động tách biệt với các dịch vụ khác các thành phần. Tất cả điều này một lần nữa đặt ra những hạn chế về mức độ hiểu biết của cả nhà phát triển và quản trị viên.
Những “sự thay đổi” tương tự về mức độ hiểu biết chuyên môn về một nguồn cụ thể vẫn tiếp tục cho đến ngày nay. Nhưng chúng ta lạc đề một chút, có nhiều điểm đáng nêu bật.
Kỹ sư xây dựng/Kỹ sư phát hành
Các kỹ sư có chuyên môn rất cao nổi lên như một phương tiện tiêu chuẩn hóa các quy trình và bản phát hành xây dựng phần mềm. Trong quá trình giới thiệu Agile rộng rãi, có vẻ như nhu cầu của họ đã không còn nữa, nhưng điều này không xảy ra. Sự chuyên môn hóa này xuất hiện như một phương tiện tiêu chuẩn hóa việc lắp ráp và phân phối phần mềm ở quy mô công nghiệp, tức là. sử dụng các kỹ thuật tiêu chuẩn cho tất cả các sản phẩm của công ty. Với sự ra đời của DevOps, các nhà phát triển đã mất đi một phần chức năng của họ, vì chính các nhà phát triển đã bắt đầu chuẩn bị sản phẩm để phân phối và đưa ra cơ sở hạ tầng thay đổi cũng như cách tiếp cận để phân phối nhanh nhất có thể mà không quan tâm đến chất lượng, theo thời gian, họ trở thành là điểm dừng của những thay đổi, vì việc tuân thủ các tiêu chuẩn chất lượng chắc chắn sẽ làm chậm quá trình giao hàng. Vì vậy, dần dần, một phần chức năng của các kỹ sư Xây dựng/Phát hành đã được chuyển sang vai trò của quản trị viên hệ thống.
Ops quá khác biệt
Chúng tôi tiếp tục lặp đi lặp lại sự hiện diện của nhiều trách nhiệm và việc thiếu nhân sự có trình độ đã thúc đẩy chúng tôi hướng tới sự chuyên môn hóa nghiêm ngặt, như nấm sau mưa, nhiều Hoạt động khác nhau xuất hiện:
- TechOps - quản trị viên hệ thống enikey hay còn gọi là Kỹ sư HelpDesk
- LiveOps - quản trị viên hệ thống chịu trách nhiệm chính về môi trường sản xuất
- CloudOps - quản trị viên hệ thống chuyên về đám mây công cộng Azure, AWS, GCP, v.v.
- PlatOps/InfraOps/SysOps - quản trị viên hệ thống cơ sở hạ tầng.
- NetOps - quản trị viên mạng
- SecOps - quản trị viên hệ thống chuyên về bảo mật thông tin - tuân thủ PCI, tuân thủ CIS, vá lỗi, v.v.
DevOps (về lý thuyết) là người hiểu trực tiếp tất cả các quy trình của chu kỳ phát triển - phát triển, thử nghiệm, hiểu kiến trúc sản phẩm, có khả năng đánh giá rủi ro bảo mật, quen thuộc với các phương pháp tiếp cận và công cụ tự động hóa, ít nhất là ở mức cao. Ngoài ra, cấp độ này còn hiểu được việc hỗ trợ trước và sau khi phát hành sản phẩm. Một người có khả năng đóng vai trò là người ủng hộ cho cả Hoạt động và Phát triển, điều này cho phép sự hợp tác thuận lợi giữa hai trụ cột này. Hiểu quy trình lập kế hoạch làm việc của các nhóm và quản lý kỳ vọng của khách hàng.
Để thực hiện loại công việc và trách nhiệm này, người này phải có phương tiện để quản lý không chỉ các quy trình phát triển và thử nghiệm mà còn quản lý cơ sở hạ tầng sản phẩm cũng như lập kế hoạch nguồn lực. DevOps theo cách hiểu này không thể nằm trong lĩnh vực CNTT, R&D hay thậm chí là PMO; nó phải có ảnh hưởng trong tất cả các lĩnh vực này - giám đốc kỹ thuật, Giám đốc kỹ thuật của công ty.
Điều này có đúng ở công ty của bạn không? - Tôi nghi ngờ. Trong hầu hết các trường hợp, đây là CNTT hoặc R&D.
Việc thiếu kinh phí và khả năng tác động đến ít nhất một trong ba lĩnh vực hoạt động này sẽ chuyển trọng tâm của vấn đề sang nơi dễ áp dụng những thay đổi này hơn, chẳng hạn như việc áp dụng các hạn chế kỹ thuật đối với các bản phát hành liên quan đến mã “bẩn” theo tiêu chuẩn tĩnh. các hệ thống phân tích. Nghĩa là, khi PMO đặt ra thời hạn nghiêm ngặt cho việc phát hành chức năng, R&D không thể tạo ra kết quả chất lượng cao trong thời hạn này và tạo ra kết quả tốt nhất có thể, để lại việc tái cấu trúc sau này, DevOps liên quan đến CNTT sẽ chặn việc phát hành bằng các phương tiện kỹ thuật . Việc thiếu thẩm quyền để thay đổi tình hình, trong trường hợp những nhân viên có trách nhiệm, dẫn đến biểu hiện của tinh thần trách nhiệm cao đối với những gì họ không thể tác động, đặc biệt nếu những nhân viên này hiểu và nhìn ra sai lầm cũng như cách sửa chữa - “Hạnh phúc là thiếu hiểu biết”, và hậu quả là sự kiệt sức và mất mát của những nhân viên này.
Thị trường tài nguyên DevOps
Hãy xem xét một số vị trí tuyển dụng cho vị trí DevOps từ các công ty khác nhau.
Chúng tôi sẵn sàng gặp bạn nếu bạn:
- Bạn sở hữu Zabbix và biết Prometheus là gì;
- IPtables;
- Nghiên cứu sinh Tiến sĩ BASH;
- Giáo sư Ansible;
- Chuyên gia Linux;
- Biết cách sử dụng tính năng gỡ lỗi và tìm ra các vấn đề của ứng dụng cùng với nhà phát triển (php/java/python);
- Định tuyến không làm bạn cuồng loạn;
- Đặc biệt chú ý đến bảo mật hệ thống;
- Sao lưu “mọi thứ và mọi thứ” và cũng khôi phục thành công “mọi thứ và mọi thứ” này;
- Bạn biết cách định cấu hình hệ thống sao cho đạt được mức tối đa từ mức tối thiểu;
- Thiết lập bản sao trước khi đi ngủ trên Postgres và MySQL;
- Việc thiết lập và điều chỉnh CI/CD đối với bạn cũng cần thiết như bữa sáng/trưa/tối.
- Có kinh nghiệm với AWS;
- Sẵn sàng phát triển cùng công ty;
Vì vậy:
- từ 1 đến 6 - quản trị hệ thống
- 7 - một chút quản trị mạng, cũng phù hợp với quản trị viên hệ thống, cấp trung
- 8 - một chút bảo mật, điều này là bắt buộc đối với quản trị viên hệ thống cấp trung
- 9-11 – Quản trị viên hệ thống cấp trung
- 12 — Tùy thuộc vào nhiệm vụ được giao, Quản trị viên hệ thống cấp trung hoặc Kỹ sư xây dựng
- 13 - Ảo hóa - Quản trị viên hệ thống cấp trung, hay còn gọi là CloudOps, kiến thức nâng cao về các dịch vụ của một trang web lưu trữ cụ thể, để sử dụng hiệu quả nguồn vốn và giảm tải cho việc bảo trì
Tổng hợp vị trí tuyển dụng này có thể nói Quản trị viên hệ thống cấp Trung/Cấp cao là đủ cho các anh.
Nhân tiện, bạn không nên phân chia mạnh mẽ quản trị viên trên Linux/Windows. Tất nhiên, tôi hiểu rằng các dịch vụ và hệ thống của hai thế giới này là khác nhau, nhưng cơ sở của tất cả đều giống nhau và bất kỳ quản trị viên có lòng tự trọng nào cũng quen thuộc với cả thế giới này và thế giới kia, và ngay cả khi anh ta không quen, điều đó sẽ không khó để một quản trị viên có năng lực làm quen với nó.
Hãy xem xét một vị trí tuyển dụng khác:
- Có kinh nghiệm xây dựng hệ thống chịu tải cao;
- Kiến thức tuyệt vời về hệ điều hành Linux, phần mềm hệ thống chung và web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Có kinh nghiệm với các hệ thống ảo hóa (KVM, VMWare, LXC/Docker);
- Thành thạo các ngôn ngữ kịch bản;
- Hiểu biết về nguyên tắc hoạt động của mạng giao thức mạng;
- Hiểu biết về các nguyên tắc xây dựng hệ thống có khả năng chịu lỗi;
- Độc lập và chủ động;
Chúng ta hãy nhìn vào:
- 1 – Quản trị viên hệ thống cấp cao
- 2 - Tùy thuộc vào ý nghĩa được đưa vào ngăn xếp này - Quản trị viên hệ thống cấp trung/cấp cao
- 3 - Kinh nghiệm làm việc, bao gồm, có thể có nghĩa là - “Cụm không phát sinh mà được tạo và quản lý các máy ảo, có một máy chủ Docker, không có quyền truy cập vào vùng chứa” - Quản trị viên hệ thống cấp trung
- 4 - Quản trị viên hệ thống cấp dưới - vâng, quản trị viên không biết viết các tập lệnh tự động hóa cơ bản, bất kể ngôn ngữ, không phải quản trị viên - enikey.
- 5 - Quản trị viên hệ thống cấp trung
- 6 – Quản trị viên hệ thống cấp cao
Tóm tắt - Quản trị viên hệ thống cấp trung/cấp cao
Một cái khác:
- Kinh nghiệm của Devops;
- Có kinh nghiệm sử dụng một hoặc nhiều sản phẩm để tạo quy trình CI/CD. Gitlab CI sẽ là một lợi thế;
- Làm việc với các thùng chứa và ảo hóa; Nếu bạn sử dụng docker thì tốt, nhưng nếu bạn sử dụng k8 thì tuyệt vời!
- Kinh nghiệm làm việc trong một nhóm linh hoạt;
- Kiến thức về bất kỳ ngôn ngữ lập trình nào;
Hãy xem nào:
- 1 - Hmm... ý các bác là sao nhỉ? =) Rất có thể chính họ cũng không biết đằng sau đó ẩn chứa điều gì
- 2 - Kỹ sư xây dựng
- 3 - Quản trị viên hệ thống cấp trung
- 4 - Kỹ năng mềm, hiện tại chúng tôi sẽ không xem xét nó, mặc dù Agile là một thứ khác được diễn giải theo cách thuận tiện.
- 5 - Quá dài dòng - nó có thể là ngôn ngữ kịch bản hoặc ngôn ngữ được biên dịch. Tôi tự hỏi liệu viết bằng Pascal và Basic ở trường có phù hợp với họ không? =)
Tôi cũng muốn để lại một ghi chú về điểm 3 để củng cố sự hiểu biết về lý do tại sao quản trị viên hệ thống lại đề cập đến điểm này. Kubernetes chỉ là một sự phối hợp, một công cụ bao bọc các lệnh trực tiếp tới trình điều khiển mạng và máy chủ ảo hóa/cách ly trong một vài lệnh và cho phép bạn giao tiếp với chúng một cách trừu tượng, chỉ vậy thôi. Ví dụ: hãy lấy 'build framework' Make, nhân tiện, tôi không xem xét một framework. Vâng, tôi biết về xu hướng đẩy Make đến bất cứ đâu, nơi cần thiết và không cần thiết - ví dụ như gói Maven vào Make, một cách nghiêm túc?
Về cơ bản, Make chỉ là một trình bao bọc trên shell, đơn giản hóa các lệnh biên dịch, liên kết và môi trường biên dịch, giống như k8.
Một lần, tôi đã phỏng vấn một anh chàng sử dụng k8 trong công việc của anh ấy trên OpenStack và anh ấy nói về cách anh ấy triển khai các dịch vụ trên đó, tuy nhiên, khi tôi hỏi về OpenStack, hóa ra là nó được quản lý cũng như được nâng lên bởi hệ thống. quản trị viên. Bạn thực sự nghĩ rằng một người đã cài đặt OpenStack, bất kể anh ta sử dụng nền tảng nào, đều không thể sử dụng k8s? =)
Người nộp đơn này thực sự không phải là DevOps mà là Quản trị viên hệ thống và chính xác hơn là Quản trị viên Kubernetes.
Hãy để chúng tôi tóm tắt lại một lần nữa - Quản trị viên hệ thống cấp trung/cấp cao sẽ là đủ đối với họ.
Cân nặng bao nhiêu gam
Mức lương đề xuất cho các vị trí tuyển dụng được chỉ định là 90k-200k
Bây giờ tôi muốn so sánh giữa phần thưởng bằng tiền của Quản trị viên hệ thống và Kỹ sư DevOps.
Về nguyên tắc, để đơn giản hóa mọi thứ, bạn có thể phân bổ điểm dựa trên kinh nghiệm làm việc, mặc dù điều này sẽ không chính xác, nhưng với mục đích của bài viết thì như vậy là đủ.
Một trải nghiệm:
- lên đến 3 năm – Junior
- đến 6 tuổi – Trung cấp
- hơn 6 – Cao cấp
Trang web tìm kiếm nhân viên cung cấp:
Quản trị viên hệ thống:
- Junior - 2 tuổi - 50k chà.
- Trung - 5 tuổi - 70k chà.
- Cao cấp - 11 tuổi - 100k chà.
Kỹ sư DevOps:
- Junior - 2 tuổi - 100k chà.
- Giữa - 3 tuổi - 160k chà.
- Cao cấp - 6 tuổi - 220k chà.
Theo kinh nghiệm của “DevOps”, trải nghiệm đã được sử dụng ít nhất đã ảnh hưởng đến SDLC bằng cách nào đó.
Từ những điều trên cho thấy trên thực tế, các công ty không cần DevOps và họ cũng có thể tiết kiệm ít nhất 50% chi phí dự kiến ban đầu bằng cách thuê Quản trị viên; hơn nữa, họ có thể xác định rõ ràng hơn trách nhiệm của người họ đang tìm kiếm và đáp ứng nhu cầu nhanh hơn. Chúng ta cũng không nên quên rằng việc phân chia trách nhiệm rõ ràng cho phép chúng ta giảm bớt các yêu cầu về nhân sự, cũng như tạo ra bầu không khí thuận lợi hơn trong nhóm do không có sự chồng chéo. Phần lớn các vị trí tuyển dụng đều có đầy đủ các tiện ích và nhãn DevOps nhưng chúng không dựa trên yêu cầu thực tế đối với Kỹ sư DevOps mà chỉ yêu cầu đối với quản trị viên công cụ.
Quá trình đào tạo kỹ sư DevOps cũng chỉ giới hạn ở một tập hợp công việc, tiện ích cụ thể và không cung cấp hiểu biết chung về các quy trình cũng như sự phụ thuộc của chúng. Chắc chắn sẽ rất tốt khi một người có thể triển khai AWS EKS bằng Terraform, kết hợp với sidecar Fluentd trong cụm này và ngăn xếp AWS ELK cho hệ thống ghi nhật ký trong 10 phút, chỉ sử dụng một lệnh trong bảng điều khiển, nhưng nếu anh ta không hiểu nguyên tắc tự xử lý nhật ký và mục đích sử dụng chúng, nếu bạn không biết cách thu thập số liệu về chúng và theo dõi sự xuống cấp của dịch vụ, thì đó vẫn sẽ là enikey biết cách sử dụng một số tiện ích.
Tuy nhiên, nhu cầu tạo ra nguồn cung và chúng tôi nhận thấy một thị trường cực kỳ nóng cho vị trí DevOps, nơi các yêu cầu không tương ứng với vai trò thực tế mà chỉ cho phép quản trị viên hệ thống kiếm được nhiều tiền hơn.
Vậy họ là ai? DevOps hay quản trị viên hệ thống tham lam? =)
Làm thế nào để tiếp tục sống?
Người sử dụng lao động nên đưa ra các yêu cầu chính xác hơn và tìm kiếm chính xác những người cần thiết, chứ không nên dán nhãn. Bạn không biết DevOps làm gì - bạn không cần chúng trong trường hợp đó.
Công nhân - Học hỏi. Không ngừng nâng cao kiến thức của bạn, nhìn vào bức tranh tổng thể về các quá trình và theo dõi con đường dẫn đến mục tiêu của bạn. Bạn có thể trở thành bất cứ ai bạn muốn, bạn chỉ cần cố gắng.
Nguồn: www.habr.com