DevOps 또는 임금 손실과 IT 산업의 미래

오늘날의 상황에서 가장 슬픈 점은 IT가 점차 1인당 책임 수에 '그만'이라는 단어가 없는 산업으로 변해가고 있다는 점입니다.

공석을 읽을 때 때로는 2-3명이 아닌 회사 전체가 한 사람으로 구성되어 모두가 서두르고 기술 부채가 늘어나고 신제품을 배경으로 한 오래된 유산이 완벽해 보입니다. 코드의 도크와 코멘트, 신제품은 빛의 속도로 작성되지만 결국 작성 후 1년 동안 사용할 수 없으며 올해는 이익을 얻지 못하는 경우가 많습니다. ”는 서비스 매출보다 높습니다. 투자자의 돈은 아직 작동하지 않지만 이미 작동하는 서비스로 온라인에 출시된 서비스를 유지하는 데 소비됩니다.
예를 들어, 오래된 게임의 리마스터가 업계 전체 역사상 가장 낮은 평가를 받은 유명한 회사입니다. 저도 이 제품을 구매한 사람 중 하나였는데, 지금도 이 제품은 정말 효과가 좋고, 이론상 이런 형태로 판매되어서는 안 됩니다. 환불, 등급 하락, 서비스 작업에 대한 불만으로 인해 포럼에서 수많은 사용자 금지. 패치의 개수가 놀랍지는 않지만 무섭지만 그래도 제품을 사용할 수 없습니다. 91년부터 발전해 온 기업이 이 같은 결과를 낳는다면 이제 막 창업한 기업의 상황은 더욱 심각하다.

하지만 서비스 사용자 입장에서 이러한 접근 방식의 결과를 살펴봤으니, 이제 직원들이 겪었던 문제점을 살펴보겠습니다.

DevOps 팀이 존재해서는 안 된다는 말, 이것이 방법론이라는 말 등을 자주 듣습니다. 하지만 문제는 어떤 이유에서든 기업이 NOK, DBA, 인프라 및 빌드 엔지니어를 찾는 것을 중단했다는 것입니다. 이제는 모두 단일 DevOps 엔지니어입니다. . 물론 개별 회사에는 여전히 그러한 공석이 있지만 그 수가 점점 줄어들고 있습니다. 많은 사람들이 이것을 개발이라고 불렀는데, 저는 개인적으로 이것이 저하되는 것을 보았습니다. 모든 영역에서 좋은 수준의 지식을 유지하는 동시에 8시간 이상 일할 수 없습니다. 당연히 이것은 환상입니다. 실제로 많은 IT 종사자들이 12시간, 14시간을 강제로 일하는데 그 중 8시간은 급여를 받고, “업무를 주었는데 문서나 비뚤어진 것도 없고 서비스 비용이 돈이 든다”는 이유로 휴가도 없이 일하는 경우가 많다. 그리고 클라우드에서의 실수로 인해 기본적으로 몇 달 안에 급여를 받을 수 없습니다. 특히 개인 기업가로 일하는 경우에는 더욱 그렇습니다. 우리는 책임 분담과 함께 본질적으로 비즈니스에 대한 발언권을 상실하고 있습니다. 관리자가 개발 프로세스에 대해 전혀 이해하지 못한 채 개입하고 비즈니스 데이터와 애플리케이션 운영을 혼동한다는 사실에 점점 더 직면하고 있습니다. 그 결과 혼란이 시작됩니다.

혼돈이 시작되면 기업은 범인을 찾고 싶어하는데 여기에는 보편적인 범인이 필요합니다. 10명이 넘는 사람에게 책임을 전가하기는 어렵기 때문에 관리자는 직책을 병합합니다. 그의 과실을 증명하십시오. 그리고 민첩한 조건에서는 "유죄"를 찾고 채찍질하는 것이 경영 분야에서 비즈니스를 수행하기 위한 방법론의 기초입니다. Agile은 오래 전에 IT에서 나왔고, 그 주요 개념은 일상적인 결과의 요구 사항이 되었습니다. 문제는 고도로 전문화된 전문가가 매일 결과를 항상 얻을 수 있는 것은 아니라는 점입니다. 이는 보고하기가 더 어렵다는 것을 의미하며, 이것이 기업이 "모든 분야의 전문가"를 원하는 또 다른 이유입니다. 그러나 물론 주된 이유는 급여입니다. 모든 변화의 주된 이유입니다. 보너스를 위해 사람들은 자신과 그 사람을 위해 일하기로 동의했습니다. 그러나 결국에는 다른 영역과 마찬가지로 제공되는 더 많은 서비스에 대해 더 적은 비용을 지불하는 것이 이제 책임이 되었습니다.

요즘에는 개발자도 배포할 수 있어야 하고 DevOps 엔지니어와 함께 인프라에서 작업해야 한다는 기사를 자주 볼 수 있습니다. 하지만 이것이 어떤 결과를 가져올까요? 맞습니다. 서비스 품질 저하, 개발자 품질 저하입니다. 불과 이틀 전 개발자에게 다른 호스트에서 쓰고 읽을 수 있다고 설명했더니 이런 건 본 적도 없다고 입에 거품을 물었지만 설정에는 orm 호스트, 포트, DB, 사용자가 있습니다. , 비밀번호 그리고 그게 다입니다… 하지만 개발자는 배포를 실행하고 Yam을 작성하는 방법을 알고 있습니다. 그러나 그는 이미 코드의 단위 테스트와 주석을 잊어버렸습니다.

결과적으로 우리는 지속적인 초과 근무, 근무 시간 외의 문제에 대한 해결책 찾기, 주말에 대한 지속적인 교육, 수입 증가가 아닌 해상 유지 등을 봅니다. 개발자는 CI/CD로 DevOps 엔지니어를 도와야 하는데, 개발자가 시간이 없으면 막히기 시작하고 관리자는 두뇌를 퇴비화하기 시작하며 이것이 초과근무 욕구를 높이는 데 도움이 되지 않으면 그런 다음 벌금과 벌금을 적용하면 그 사람은 새 일자리를 찾고 에베레스트 규모의 기술 부채를 남기고 결과적으로 개발자들 사이에서 부채가 증가하기 시작합니다. 그들은 이전 또는 새로운 DevOps 엔지니어를 도울 시간을 갖기 위해 리팩토링을 덜 사용하여 코드를 작성해야 하며 관리자는 모든 것에 매우 만족합니다. 범인이 거기 있고 즉시 볼 수 있기 때문입니다. 이는 기본 규칙을 의미합니다. 애자일 관리를 따르면 범인이 발견되고 그를 채찍질한 결과가 표시됩니다.

나는 한때 ITGM에서 "우리가 "아니요"라고 말하는 법을 배울 때"라는 프레젠테이션을 한 적이 있습니다. 그 결과는 매우 드러났습니다. 수많은 사람들이 이 단어가 금기시된다고 믿고 있으며, 우리가 그렇게 생각하지 않는 한 문제는 더욱 커질 것입니다.

이 기사는 부분적으로 나에게서 영감을 받았습니다. 이 기사, 그러나 나중에 덜 정중한 용어로 설명할 수도 있습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

직장에서 고용주가 여러 사람을 당신으로 대체하려고 할 때 만난 적이 있습니까?

• 65,6%네, 정기적으로 접합니다183

• 5,4%네, 1번 발생했습니다15

• 15,4%눈치채지 못했어요43

• 13,6%나는 워커홀릭이다. 나는 초과근무를 한다38

279명의 사용자가 투표했습니다. 34명의 사용자가 기권했습니다.

출처 : habr.com