DevOpsForum 2019. 빨리 DevOps 구현을 기대하세요

저는 최근 Logrocon이 주최하는 DevOpsForum 2019에 참석했습니다. 이번 컨퍼런스에서 참가자들은 비즈니스와 개발 및 정보 기술 서비스 전문가 간의 효과적인 상호 작용을 위한 솔루션과 새로운 도구를 찾으려고 노력했습니다.

컨퍼런스는 성공적이었습니다. 유용한 보고서가 많이 있었고, 흥미로운 프리젠테이션 형식이 있었으며, 연사들과의 많은 소통이 있었습니다. 그리고 아무도 나에게 아무것도 팔려고 하지 않았다는 것이 특히 중요합니다. 최근 대규모 컨퍼런스의 연사들이 유죄를 선고받은 일입니다.

Raiffeisenbank, Alfastrakhovanie, Mango Telecom의 자동화 구현 경험 및 컷에 따른 기타 세부 사항의 연설에서 발췌.

제 이름은 Yana입니다. 저는 테스터로 일하고 있으며 자동화와 DevOps 작업을 수행하고 있으며 컨퍼런스와 모임에 가는 것을 좋아합니다. 지난 XNUMX년 동안 저는 Oleg Bunin의 컨퍼런스(HighLoad++, TeamLead Conf), Jug 이벤트(Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow에 참석했습니다.

우선 컨퍼런스 프로그램에 주목합니다. 나는 보고서가 무엇에 관한 것인지보다는 발표자를 더 많이 봅니다. 보고서가 매우 기술적이고 흥미로운 것으로 판명되더라도 보고서의 일부 모범 사례를 회사에 적용할 수 있다는 것은 사실이 아닙니다. 그리고 스피커가 필요합니다.

Raiffeisenbank 파이프라인 끝의 조명

보통 나는 관심 있는 스피커를 옆에서 찾아봅니다. DevOpsForum 2019에서 Raiffeisenbank의 Mikhail Bizhan 연사가 저의 관심을 끌었습니다. 연설에서 그는 팀이 DevOps에 점차 관심을 갖게 되는 방법, 그것이 필요한 이유, DevOps 혁신 아이디어를 비즈니스에 판매하는 방법에 대해 이야기했습니다. 글쎄요, 일반적으로 파이프라인 끝에서 빛을 보는 방법에 대해 이야기했습니다.

Raiffeisenbank 자동화 이사 Mikhail Bizhan

이제 회사에는 "DevOps"가 없습니다. 즉, 그는 일하지만 모든 팀에서 일하지는 않습니다. DevOps를 구현할 때 특정 엔지니어 측면과 제품의 필요성 및 이 제품이 구축된 플랫폼의 성숙도 측면에서 팀의 준비 상태에 의존합니다. Misha는 DevOps가 필요한 이유를 기업에 설명하는 방법을 설명했습니다.

은행 부문에는 서비스 비용, 고객 기반 확장 등 여러 가지 성장 동인이 있습니다. 서비스 비용을 늘리는 것은 그다지 좋은 동인이 아니지만 고객 기반을 늘리는 것은 그 반대입니다. 경쟁자가 객관적으로 멋진 제품을 출시하면 모든 고객이 그곳으로 가고 시간이 지남에 따라 시장은 평준화됩니다. 따라서 은행이 중점을 두는 것은 신제품을 시장에 출시하고 출시 속도를 높이는 것입니다. 이것이 바로 DevOps의 목적이며 기업은 이를 이해합니다.

다음 중요한 참고 사항: DevOps가 항상 출시 시간을 단축하는 것은 아닙니다. DevOps는 단독으로 작동할 수 없으며, 개발부터 생산까지(코드에서 고객까지) 제품을 만들고 시장에 출시하는 프로세스의 일부일 뿐입니다. 그러나 코드 이전의 모든 것은 DevOps와 직접적인 관련이 없습니다. 즉, 마케팅 담당자는 수년간 시장을 연구하고 경쟁사를 따라잡는 데 평생을 보낼 수 있습니다. 클라이언트가 필요로 하는 것이 무엇인지 빠르게 이해하고 이 기능 또는 해당 기능의 구현을 계획해야 합니다. 이는 DevOps가 작동하고 회사가 목표를 달성하는 데 충분하지 않은 경우가 많습니다. 따라서 우선 Raiffeisenbank는 DevOps 사용 방법을 배워야 한다는 업계 의견에 동의했습니다. 자동화를 위한 자동화는 신규 고객 확보에 큰 도움이 되지 않습니다.

일반적으로 Misha는 DevOps를 구현해야 하지만 현명하게 구현해야 한다고 생각합니다. 그리고 우리는 변화가 시작될 때 팀의 생산성이 떨어지고 돈을 덜 벌지만 그것이 정당화될 것이라는 사실에 대비해야 합니다.

Mango Telecom의 테스트 자동화

테스터로서 저에게 또 다른 흥미로운 보고서는 Mango Telecom의 Egor Maslov가 제공한 것입니다. 프레젠테이션 제목은 "SCRUM 팀의 전체 테스트 주기 자동화"였습니다. Egor는 DevOps가 SCRUM을 위해 특별히 제작되었다고 생각하지만 동시에 SCRUM 팀에 DevOps를 도입하는 것은 상당히 문제가 있습니다. 이는 SCRUM 팀이 항상 어딘가에서 실행 중이기 때문에 발생하며 혁신으로 인해 주의가 산만해지고 프로세스를 다시 구축할 시간이 없습니다. 문제는 SCRUM이 팀 내 하위 팀(테스트 팀, 개발 팀 등)을 분리하지 않는다는 사실에도 있습니다. 게다가 기존 프로세스를 자동화하려면 문서가 필요하며 SCRUM에는 대부분 문서가 완전히 존재하지 않습니다. "제품은 어떤 종류의 글쓰기보다 더 중요합니다."

SCRUM으로 전환한 후 테스터는 기능 테스트 방법에 대해 개발자와 상담하기 시작했습니다. 점차적으로 기능의 양이 증가하고 문서가 없었으며 테스트에서 다루지 않은 기능에서 많은 버그를 발견하기 시작했으며 일반적으로 누가 언제 테스트했는지 더 이상 명확하지 않았습니다. 간단히 말해서 - 혼란과 동요. 우리는 테스트 자동화로 전환하기로 결정했습니다. 그러나 그때에도 완전한 실패가 있었습니다. 그들은 사내 테스터에게 알려지지 않은 스택에 글을 쓰는 아웃소싱 자동화 전문가를 고용했습니다. 물론 자동 테스트를 위한 프레임워크는 작동했지만 아웃소싱 업체가 떠난 후에도 XNUMX주 동안 지속되었습니다. 다음은 두 번째 자동 테스트를 도입하려는 시도였습니다. 이는 모든 것이 회사 내에서 스스로(올바른 벡터: 내부적으로 전문 지식 구축), SCRUM 프레임워크 내에서 구축되고 그 과정에서 문서를 작성해야 한다는 사실에서 시작되었습니다. 자동화를 위한 스택은 제품 스택과 동일해야 합니다(여기서 추가하고 있으므로 JavaScript 프로젝트를 다른 것으로 테스트하지 마십시오). 스프린트가 끝나면 팀 전체에서 자동 테스트가 어떻게 작동하는지 시연했습니다(유용함). 따라서 자동화 프로세스에 모든 팀 구성원의 참여가 증가했을 뿐만 아니라 자동 테스트에 대한 신뢰와 이 자동 테스트가 확실히 사용될 가능성이 높아졌습니다(지속적인 실패로 인해 한 달 안에 설명되지 않음).

그건 그렇고, DevOpsForum 2019에는 오랫동안 알려져 있고 제 생각에는 유용한 연설 형식인 개방형 마이크가 있었습니다. 이렇게 돌아다니며 보고서를 듣고 회의에서 특정 주제나 문제를 논의하고 문제 해결과 관련된 경험을 공유할 가치가 있다고 결정합니다.

나는 또한 주최측이 짧은 보고서를 연속적으로 작성하는 것을 발견했습니다. 각 보고서는 10분 이내로 진행되며 질문이 이어집니다. 이렇게 하면 한 번에 많은 주제를 다루고 관심 있는 연사에게 질문을 할 수 있습니다.

프레젠테이션 중간에 컨퍼런스 파트너 부스를 돌아다니며 많은 물건을 훔치거나 얻었습니다. 아, 유인물이 마음에 드네요!

Alfastrakhovanie의 개발 이사와의 라운드 테이블 및 DevOps 문제

DevOpsForum 2019의 가장 멋진 점은 DevOps 전문가들과 함께한 한 시간짜리 본회의였습니다. XNUMX명의 세션 참가자가 초대되어 DevOps를 다양한 각도에서 살펴보았습니다. Anton Isanin(Alfastrakhovanie, 개발 이사), Nailya Zamashkina(Fintech Lab, 운영 이사), Oleg Egorkin(Rostelecom, Agile 코치) 및 Anton Martyanov(독립 전문가, DevOps 살펴보기) 비즈니스 관점에서).

전문가들이 사람들에게 더 가까이 앉자 일이 일어나기 시작했습니다. 한 시간 동안 청중 중 참가자들이 질문을 하고 전문가들이 랩을 맡았습니다. 때로는 실제 토론이있었습니다. 예를 들어 DevOps 엔지니어가 전혀 필요한지, 시스템 관리자로서 교육을 받을 수 없는 이유는 무엇인지, DevOps를 모든 사람에게 제공해야 하는지, 그 가치는 무엇인지 등 질문이 매우 달랐습니다.

그런 다음 Anton Isanin과 개인적으로 이야기를 나눴습니다. 우리는 DevOps 문화를 모든 가정에 도입해야 할 필요성에 대해 논의하고 DevOps 혁신의 어두운 면을 밝혔습니다.

모두가 함께 모여 제품과 비즈니스, 팀 모두에 DevOps가 필요하다고 결정했다고 가정해 보겠습니다. 구현해 보겠습니다. 모든 것이 잘되었습니다. 우리는 숨을 내쉬었습니다. DevOps를 통해 우리는 고객에게 더 가까이 다가갈 수 있게 되었으며 이제 고객의 모든 희망 사항을 신속하게 이행할 수 있습니다. 그 결과 우리는 엄격한 규정과 요구 사항을 갖춘 대규모 Ops 부서를 보유하고 있으며 지속적으로 제품의 결함을 찾아내고 수많은 요청을 생성합니다. 또한 클라이언트가 예기치 않게 버튼을 녹색 대신 노란색으로 지정하기를 원하더라도 모든 결함에는 "긴급" 상태가 할당됩니다. 프로젝트가 성장하고 릴리스 수가 늘어나고 그에 따라 클라이언트의 새로운 기능에 대한 결함과 오해의 수가 늘어나고 있습니다. Ops에서는 결함 보고를 유지하기 위해 10명의 인력을 더 고용하고, 개발팀에서는 결함 종결을 위해 15명을 더 고용합니다. 그리고 새로운 기능을 도입하는 대신 팀은 끝없는 SD를 사용하여 사용자에게 기능을 설명하고 동시에 지원합니다. 결과적으로 Ops와 개발은 모두 작동하지만 클라이언트와 비즈니스는 만족스럽지 않습니다. 새로운 기능이 중단됩니다. DevOps는 존재하는 것 같지만 존재하지 않는 것 같습니다.

DevOps 구현의 필요성과 관련하여 Anton은 이것이 비즈니스 규모에 직접적으로 달려 있다고 분명히 밝혔습니다. XNUMX년에 하나의 클라이언트에 서비스를 제공하여 회사에 XNUMX억 달러의 수익을 가져다 준다면 DevOps는 필요하지 않습니다(이 클라이언트에 정기적으로 새로운 변경 사항을 적용할 필요가 없다면). 모든 것이 초콜릿으로 덮여 있습니다. 하지만 사업이 성장하고 더 많은 고객이 등장한다면 이를 준수해야 합니다. 일반적으로 처음에는 회사에 멋진 Ops가 없습니다. 먼저 제품을 자르고 나서야 제품이 작동하려면 서버를 주시하고 소모품을 모니터링해야 한다는 것을 이해합니다. 그때부터 Ops가 탄생하게 됩니다. Ops는 별도의 부서로서 개발에 많은 장벽을 세우기 시작하고 모든 배송이 중단되기 시작할 것이라는 점을 이해해야 합니다. 즉, 이 경우 DevOps 문화는 이미 관련성이 있지만 그 어두운 측면을 잊어서는 안됩니다.

출처 : habr.com