DevOps 란 무엇이며 DevOps 엔지니어가 수행하는 작업
DevOps(개발 운영 또는 내부 운영)라는 용어는
풍부한 관행은 DevOps를 다른 사람들과 더 가깝게 만듭니다.Agile 방법을 사용하는 IT 분야에서 널리 사용됩니다. 변화하는 요구 사항에 적응할 수있는 반복적 인 설계 접근 방식입니다. 따라서 DevOps 전문가는 제품을 개선하고 비즈니스 프로세스를보다 예측 가능하고 투명하게 만들기 위해 노력합니다. 또한 출시 시간 단축과 같은 비즈니스 지표를 개선합니다. 제품 개발 시작부터 시장 출시까지 걸리는 시간입니다. 소프트웨어 및 시스템 접근 방식을 만드는 데 걸리는 시간을 늘리는 요인에 대한 지식을 통해 DevOps 엔지니어는 생산을 지속적이고 빠르게 수행 할 수 있습니다. 더 명확하게하기 위해 자동차 조립 용 컨베이어 벨트로 비유를 그릴 수 있습니다. 모든 부품은 조립 중에 완벽하게 맞도록 미리 설계되었습니다. 엔진을 설계하는 엔지니어는 바퀴, 브레이크 등과 함께 작동하는 방식에 대해 생각합니다. DevOps도 마찬가지입니다. 개발자보다 더 많은 제품에 대한 책임을지고 모든 팀이 협업하도록합니다.
핑크 포니 월드 : 패션 철학을위한 레이스
그러나 모든 회사에 DevOps가 필요한 것은 아닙니다. 예를 들어, 디지털 제품 생산에 관여하지 않는 기존 IT 부서가없는 팀에서는 DevOps 철학이 전혀 적용되지 않습니다. 이러한 영역에는 고객이 상호 작용하는 IT 제품에 얼마나 만족하는지에 따라 수익이 직접적으로 좌우되지 않는 회사가 포함됩니다. 또한 중소기업에는 적합하지 않은 경우가 많습니다. 방법론은 기존의 많은 비즈니스 프로세스와 기업 문화의 변화를 필요로합니다. 소규모 기업은 프로젝트 경제의 관점에서 이러한 변화를 용납하지 않을 수 있습니다.
디지털 혁신의 유행병은 종종그러한 회사의 머리에 관한 것입니다. 끊임없는 최적화를 추구하면서 그들은 비즈니스에 영향을 미치는 다른 요소를 잊어 버립니다. 그 결과 기업은 비용과 효율성을 잃고 최악의 경우 수년에 걸쳐 구축 된 비즈니스 프로세스를 잃게됩니다. IT 거물, 은행, 대규모 무역 및 산업 이벤트는 또 다른 문제입니다. 그들에게 DevOps는 매우 유익 할 수 있습니다. 따라서 2017 년 Alfa-Bank의 연례 보고서에 따르면 방법론의 도입으로 개발 및 구현을 60 배까지 가속화 할 수있었습니다.
직원 워크샵 대신 Stakhanovite-mnogostanochnik
물론 이러한 광범위한 기능은 어렵습니다따라서 이상적으로는 전체 교차 기능 팀이 DevOps에 참여합니다. 여기에는 역할 및 프로세스 및 제품 관리자, 인프라 코드 개발자, 엔지니어 및 기타 여러 역할의 전문가가 포함됩니다. 그러나 러시아에서는 DevOps 전문가가 종종 제품 제작 비용을 절약하는 유행하는 방법이 될 수 있습니다. 일반적으로 이러한 상황은 회사의 최고 관리자가 디지털 혁신의시기가되었다고 결정한 후에 발생합니다. 회사는 새로운 전문가를 긴급하게 모집하거나 기존 개발자 및 시스템 관리자의 책임 목록을 확장합니다. 결과적으로 채용 서비스는 DevOps 엔지니어를위한 공석이 아니라 다중 스테이션 직원을위한 공석을 생성합니다.
그러한 직원은 개별적으로 의무를 질 수 있습니다.서버를 구성하고 케이블 링 시스템을 배치 한 다음 오류를 추적하고 데이터베이스 및 프로젝트 호스팅을 구성합니다. 이 예는 극단적이지만 실제입니다. 결과적으로 직원은 빠르게 소진되고 회사 작업에서 방법론을 구현하지 못합니다. DevOps 전문가를 전체 시스템의 운영 모니터링과 함께 동시에 많은 작업을 처리 할 수있는 마술사로 대하는 것은 비즈니스에 이익을 가져다주지 않습니다.
또 다른 일반적인 문제는팀을 서로 잘 어울리지 않는 두 그룹으로 나누는 것입니다. IT 회사에 일반적인 작업 절차를 변경할 수있는 DevOps 부서가 있다고 상상해보십시오. 그러나 이러한 규칙은 다른 개발자에게 여전히 구속력이 있습니다. 물론이 경우 협력과 업무의 "원활 함"에 대해 이야기 할 필요는 없습니다. 두 팀이 충돌하기 시작하고 생산성이 떨어집니다.
보류중인 분말 배럴 : DevOps는 단순한 기술이 아닙니다.
DevOps 부서의 작업 중 하나는회사의 다른 IT 전문가 간의 의사 소통. DevOps 엔지니어는 기술 및 디버그 프로세스를 도입 할뿐만 아니라 비즈니스 과정에 개발 팀을 몰입시켜야합니다. 책임을 공유하고 역량을 높이는 데 도움이됩니다. 그럼에도 불구하고, 그러한 전문가들은 보통 그들과 능력을 향상시켜야하는 사람들 모두를위한 진부한 시간 부족으로 인해 순전히 기술적 인 작업에 참여합니다.
그 결과 유행을 도입 한 사실로 인해모든 사람이 기술을 사용하고 지식과 기술이 한 부서에 집중되어 치명적인 상황을 포함한 문제 상황이 발생합니다. DevOps 엔지니어가 만든 새로운 솔루션은 다른 부서의 조정 작업없이 초기에 해결해야 할 문제만큼 많은 문제를 가져올 수 있습니다. 이는 DevOps 전문가가 국내 사람들이 종종 생각하는 것처럼 처음부터 기업 문화를 만들어야한다는 의미는 아닙니다. 지도자. 디지털 프로덕션 파이프 라인의 통합과 새로운 기술 및 커뮤니케이션의 이전을 장려하는 것은 회사의 리더가해야합니다. 이것이 없으면 DevOps 팀조차도 제대로 개발되지 않고 팀과 지식을 공유하지 않을 것입니다.
DevOps 아웃소싱도외부 전문가와 상담합니다. 첫 번째 경우, 외부 팀은 고객 회사의 요구가 아니라 시장에서 인용 된 표준 기술 세트에 의해 안내됩니다. 클라이언트에게 이것은 복권입니다. 아웃소싱 된 직원은 시장에서 DevOps에 대해 모호한 이해를 사용합니다. 결과적으로 비즈니스 프로세스는 점점 더 복잡해 지지만 비즈니스에 어떠한 이점도 가져 오지 않습니다. 종종 기업은 이러한 접근 방식을 권장합니다. 예를 들어 개발 프로세스를 변경하지 말라고 요청합니다. 이것이 바로 DevOps의 개념과 상반되는 것이 분명합니다.
길고, 비싸고, 문제 : 러시아어의 가혹한 DevOps
DevOps 철학을 적용하는 대신모든 비즈니스 프로세스에 대해 국내 기업은 종종 작업 속도에 영향을 미치지 않는 도구 작업을 선호합니다. 예를 들어 그 결과 중 하나는 "벽돌 벽"입니다. 즉, 시스템 관리자 팀인 운영은 격리 된 상태로 유지되고 개발자는 응용 프로그램을 해당 팀에 던집니다. 물론 그 결과 도구 상자는 여전히 개선되고 있습니다. 그러나 근본적인 변화가 일어나지 않고 투명성이 증가하지 않으며 IT 팀 협업이 개선되지 않습니다.
그들이 우연히 만난 또 다른 걸림돌DevOps를 구현할 때 관리자 - 기업 지식 기반이 부족합니다. 2019년 DORA 보고서에 따르면 회사 내부 정보 소스를 사용한 팀은 다른 팀보다 1.73배 더 효과적이었습니다. 이 문제는 팀이 지식을 공유하지 않는 많은 러시아 기업의 폐쇄적인 문화로 다시 귀결됩니다. 이러한 폐쇄적 성격으로 인해 기업은 기술 부채를 축적하기 시작합니다. 도구가 오래되고 아티팩트가 제거되지 않으며 문서가 업데이트되지 않습니다.
생산 안정성에 대한 객관적인 비즈니스 요구와 이에 따른 이익, 오래된 기술 기반 및 기술 부채와 결합되어 DevOps의 사용 실패로 이어집니다.
이 모든 것은 오랜 고뇌 끝에 DevOps 팀이 제공하는 새로운 솔루션이 단순히 버려지고 프로세스가 "롤백"된다는 사실로 이어집니다.
각 회사에는 자체 디지털 전환 경로가 있습니다.대부분의 경우 코드가 더 나은 방식으로 개발되고 배포되는 방식을 실제로 변경합니다. 이는 DevOps가 여전히 러시아에 존재한다는 것을 의미합니다. 매달이 방법론과 관련된 많은 공석이 시장에 나타납니다. 또 다른 한 가지는 그 뒤에 전문성과 실제 작업에 대한 다른 정의가 있다는 것입니다. 그러나 기업은 유령처럼 이상적인 IT 시스템을 쫓는 것을 멈추고 트렌디하지만 반드시 수익성이있는 것은 아닌 철학을 채택하여 자신의 요구에 우선 순위를 두어야합니다.
참조 :
블랙홀에는 우주가있을 수 있습니다. 새로운 발견에 대해 알려드립니다
질병의 3 일차에, 대부분의 COVID-19 환자는 후각을 잃고 종종 콧물로 고통받습니다.
연구 : 해저에서 발견 된 1500 만 톤의 미세 플라스틱