DevOps 접근 방식 팬을 위한 컨퍼런스

물론 우리는 다음에 대해 이야기하고 있습니다. DevOpsConf. 자세한 내용을 다루지 않으시면 30월 1일과 XNUMX월 XNUMX일에 개발, 테스트, 운영 과정을 통합하는 컨퍼런스를 개최할 예정이며, 자세한 내용을 알고 싶으시면 cat 항목을 참조하시기 바랍니다.

DevOps 접근 방식 내에서 프로젝트 기술 개발의 모든 부분은 서로 얽혀 있고 동시에 발생하며 서로 영향을 미칩니다. 여기서 특히 중요한 것은 실시간으로 변경, 시뮬레이션 및 테스트할 수 있는 자동화된 개발 프로세스를 생성하는 것입니다. 이를 통해 시장 변화에 즉각적으로 대응할 수 있습니다.

컨퍼런스에서 우리는 이러한 접근 방식이 제품 개발에 어떻게 영향을 미치는지 보여주고 싶습니다. 클라이언트를 위한 시스템의 신뢰성과 적응성이 어떻게 보장되는지. DevOps가 업무 프로세스를 구성하기 위해 회사의 구조와 접근 방식을 어떻게 변화시키고 있습니까?

무대 뒤에서

DevOps 접근 방식의 프레임워크 내에서 여러 회사가 무엇을 하고 있는지 아는 것뿐만 아니라 이것이 왜 필요한지 이해하는 것도 중요합니다. 따라서 우리는 프로그램 위원회에 전문가뿐만 아니라 DevOps 담론을 다양한 입장에서 볼 수 있는 전문가를 초대했습니다.

• 수석 엔지니어;
• 개발자;
• 팀 리더;
• CTO.

한편 이는 보고서 요청을 논의할 때 어려움과 갈등을 야기합니다. 엔지니어가 대형 사고를 분석하는 데 관심이 있다면 개발자가 클라우드와 인프라에서 작동하는 소프트웨어를 만드는 방법을 이해하는 것이 더 중요합니다. 그러나 동의함으로써 우리는 엔지니어부터 CTO까지 모든 사람에게 가치 있고 흥미로운 프로그램을 만듭니다.

우리 컨퍼런스의 목표는 단지 ​​가장 과장된 보고서를 선택하는 것이 아니라 DevOps 접근 방식이 실제로 어떻게 작동하는지, 새로운 프로세스로 이동할 때 어떤 종류의 레이크에 직면할 수 있는지 등 전반적인 그림을 제시하는 것입니다. 동시에 비즈니스 문제부터 특정 기술까지 내려가는 콘텐츠 부분을 구축합니다.

회의 섹션은 이전과 동일하게 유지됩니다. 지난 번에.

• 인프라 플랫폼.
• 코드로서의 인프라.
• 지속적인 전달.
• 피드백.
• DevOps의 아키텍처, CTO를 위한 DevOps.
• SRE 관행.
• 교육 및 지식 관리.
• 보안, DevSecOps.
• DevOps 혁신.

Call for Papers: 우리가 찾고 있는 보고서의 종류

우리는 조건에 따라 컨퍼런스의 잠재 청중을 엔지니어, 개발자, 보안 전문가, 팀 리더 및 CTO의 5개 그룹으로 나누었습니다. 각 그룹에는 컨퍼런스에 참석하려는 동기가 있습니다. 그리고 이러한 입장에서 DevOps를 살펴보면 주제에 초점을 맞추는 방법과 강조할 부분을 이해할 수 있습니다.

엔지니어의 경우, 인프라 플랫폼을 만드는 사람이라면 기존 트렌드를 이해하고 현재 어떤 기술이 가장 발전했는지 이해하는 것이 중요합니다. 그들은 이러한 기술을 사용하고 의견을 교환하는 실제 경험에 대해 배우고 싶어할 것입니다. 엔지니어는 일부 하드코어 사고를 분석하는 보고서를 듣고 기뻐할 것이며, 우리는 그러한 보고서를 선택하고 다듬기 위해 노력할 것입니다.

개발자용 와 같은 개념을 이해하는 것이 중요하다. 클라우드 네이티브 애플리케이션. 즉, 클라우드와 다양한 인프라에서 작동하도록 소프트웨어를 개발하는 방법입니다. 개발자는 소프트웨어로부터 지속적으로 피드백을 받아야 합니다. 여기서는 기업이 이 프로세스를 구축하는 방법, 소프트웨어 성능을 모니터링하는 방법, 전체 제공 프로세스가 어떻게 작동하는지에 대한 사례를 듣고 싶습니다.

사이버보안 전문가 회사 내 개발 및 변경 프로세스가 중단되지 않도록 보안 프로세스를 설정하는 방법을 이해하는 것이 중요합니다. DevOps가 그러한 전문가에게 부여하는 요구 사항에 대한 주제도 흥미로울 것입니다.

팀 리더가 알고 싶어함, 다른 회사에서 지속적인 전달 프로세스가 어떻게 작동하는지. 이를 달성하기 위해 기업은 어떤 경로를 택했으며 DevOps 내에서 개발 및 품질 보증 프로세스를 어떻게 구축했습니까? 팀 리더도 클라우드 네이티브에 관심이 있습니다. 또한 팀 내, 개발팀과 엔지니어링팀 간의 상호작용에 관한 질문도 있습니다.

에 CTO (최고 기술 담당자) 가장 중요한 것은 이러한 모든 프로세스를 연결하고 비즈니스 요구에 맞게 조정하는 방법을 찾는 것입니다. 그는 애플리케이션이 비즈니스와 클라이언트 모두에게 신뢰할 수 있는지 확인합니다. 그리고 여기서는 어떤 기술이 어떤 비즈니스 작업에 적합한지, 전체 프로세스를 구축하는 방법 등을 이해해야 합니다. CTO는 예산 책정도 담당합니다. 예를 들어, 전문가가 DevOps에서 일할 수 있도록 재교육하는 데 얼마나 많은 비용이 소요되는지 이해해야 합니다.

이 일에 대하여 할 말이 있거든 침묵하지 말고 보고서를 제출하세요. Call for Papers 마감일은 20월 XNUMX일입니다. 일찍 등록할수록 보고서를 마무리하고 프레젠테이션을 준비하는 데 더 많은 시간이 소요됩니다. 그러니 지체하지 마십시오.

글쎄, 공개적으로 말할 필요가 없다면 그냥 티켓을 사다 30월 1일과 XNUMX월 XNUMX일에 와서 동료들과 소통합니다. 우리는 그것이 흥미롭고 영감을 줄 것이라고 약속합니다.

DevOps를 보는 방법

DevOps의 의미를 정확히 이해하려면 내 보고서를 읽어보거나 다시 읽어보는 것이 좋습니다.데브옵스란?" 시장의 흐름을 따라가며 DevOps의 아이디어가 소규모 스타트업부터 다국적 기업까지 다양한 규모의 회사에서 어떻게 변화하고 있는지 관찰했습니다. 이 보고서는 일련의 질문을 기반으로 작성되었으며, 질문에 답하면 회사가 DevOps로 전환하고 있는지 또는 어딘가에 문제가 있는지 이해할 수 있습니다.

DevOps는 복잡한 시스템이므로 다음을 포함해야 합니다.

• 디지털 제품.
• 이 디지털 제품을 개발하는 비즈니스 모듈입니다.
• 코드를 작성하는 제품 팀.
• 지속적인 전달 방식.
• 서비스로서의 플랫폼.
• 서비스로서의 인프라.
• 코드로서의 인프라.
• DevOps에 내장된 안정성 유지를 위한 별도의 방법입니다.
• 모든 것을 설명하는 피드백 실습입니다.

보고서 말미에는 회사의 DevOps 시스템에 대한 아이디어를 제공하는 다이어그램이 있습니다. 이를 통해 회사에서 이미 간소화된 프로세스와 아직 구축되지 않은 프로세스를 확인할 수 있습니다.

보고서 영상을 보실 수 있습니다 여기에.

이제 보너스가 있습니다. DevOps 혁신의 가장 일반적인 문제를 다루는 RIT++ 2019의 여러 비디오.

제품으로서의 회사 인프라

Artyom Naumenko는 Skyeng의 DevOps 팀을 이끌고 회사 인프라 개발을 관리합니다. 그는 인프라가 SkyEng의 비즈니스 프로세스에 어떤 영향을 미치는지, 즉 ROI를 계산하는 방법, 계산을 위해 어떤 지표를 선택해야 하는지, 이를 개선하기 위해 작업하는 방법에 대해 설명했습니다.

마이크로서비스로 가는 길

Nixys 회사는 바쁜 웹 프로젝트 및 분산 시스템에 대한 지원을 제공합니다. 기술 이사인 보리스 에르쇼프(Boris Ershov)는 개발이 시작된 지 5년 이상 된 소프트웨어 제품을 현대적인 플랫폼으로 변환하는 방법을 설명했습니다.

일반적으로 이러한 프로젝트는 현재 엔지니어가 알지 못하는 인프라의 어둡고 오래된 구석이 있는 특별한 세계입니다. 그리고 한때 선택한 아키텍처 및 개발 접근 방식은 구식이며 비즈니스에 동일한 속도의 개발 및 새 버전 출시를 제공할 수 없습니다. 결과적으로 모든 제품 출시는 놀라운 모험으로 바뀌며, 무언가가 끊임없이 떨어지고 가장 예상치 못한 곳에서 발생합니다.

이러한 프로젝트의 관리자는 필연적으로 모든 기술 프로세스를 혁신해야 할 필요성에 직면합니다. 보고서에서 보리스는 이렇게 말했습니다.

• 프로젝트에 적합한 아키텍처를 선택하고 인프라를 정리하는 방법
• 사용할 도구는 무엇이며 변화의 길에서 직면하게 되는 함정은 무엇입니까?
• 다음에 무엇을할지.

릴리스 자동화 또는 빠르고 쉽게 제공하는 방법

Alexander Korotkov는 CIAN의 CI/CD 시스템 분야의 선도적인 개발자입니다. 그는 품질을 향상시키고 코드를 프로덕션 단계로 전달하는 시간을 5배 단축할 수 있는 자동화 도구에 대해 이야기했습니다. 그러나 이러한 결과는 자동화만으로는 달성할 수 없기 때문에 알렉산더는 개발 프로세스의 변화에도 주의를 기울였습니다.

사고는 학습에 어떻게 도움이 되나요?

Alexey Kirpichnikov는 SKB Kontur에서 5년 동안 DevOps 및 인프라를 구현해 왔습니다. 1000년 동안 그의 회사에서는 다양한 정도의 서사적인 가짜 사진이 약 36개나 발생했습니다. 예를 들어 그 중 14%는 낮은 품질의 릴리스를 프로덕션에 출시함으로써 발생했으며 XNUMX%는 데이터 센터의 하드웨어 유지 관리 작업으로 인해 발생했습니다.

회사의 엔지니어들이 수년 동안 유지해온 보고서(사후 분석) 아카이브를 통해 사고에 대한 정확한 정보를 얻을 수 있습니다. 사후 분석은 비상 신호에 가장 먼저 응답하고 모든 것을 고치기 시작한 담당 엔지니어가 작성합니다. 보고서를 작성하여 밤에 실수로 고생하는 엔지니어를 괴롭히는 이유는 무엇입니까? 이 데이터를 통해 전체 그림을 보고 인프라 개발을 올바른 방향으로 이동할 수 있습니다.

그의 연설에서 Alexey는 정말로 유용한 사후 분석을 작성하는 방법과 대기업에서 그러한 보고서의 실행을 구현하는 방법을 공유했습니다. 누군가가 어떻게 망했는지에 대한 이야기를 좋아한다면 공연 영상을 시청하세요.

DevOps에 대한 귀하의 비전이 우리의 비전과 일치하지 않을 수 있다는 것을 이해합니다. DevOps 혁신을 어떻게 보는지 아는 것은 흥미로울 것입니다. 댓글로 이 주제에 대한 경험과 비전을 공유해 주세요.

프로그램에 이미 어떤 보고서가 승인되었나요?

이번 주 프로그램 위원회는 보안, 인프라 및 SRE 관행에 관한 4개의 보고서를 채택했습니다.

아마도 DevOps 혁신의 가장 고통스러운 주제는 정보 보안 부서 직원이 개발, 운영 및 관리 간에 이미 구축된 연결을 파괴하지 않도록 하는 방법일 것입니다. 일부 회사는 정보보안 부서 없이 관리합니다.. 이 경우 정보 보안을 보장하는 방법은 무엇입니까? 그것에 대해 말할 것이다 sudo.su의 Mona Arkhipova. 그녀의 보고서에서 우리는 다음과 같은 사실을 알 수 있습니다.

• 무엇을 보호해야 하며 누구로부터 보호해야 하는가?
• 일상적인 보안 프로세스는 무엇입니까?
• IT와 정보 보안 프로세스가 어떻게 교차하는지;
• CIS CSC란 무엇이며 어떻게 구현하나요?
• 정기적인 정보 보안 점검을 수행하는 방법과 지표.

다음 보고서는 코드형 인프라 개발에 관한 것입니다. 수동 루틴의 양을 줄이고 전체 프로젝트를 혼란에 빠뜨리지 않는 것이 가능합니까? 이 질문에 오트베티 Ixtens의 Maxim Kostrikin. 그의 회사는 테라 폼 AWS 인프라 작업에 사용됩니다. 이 도구는 편리하지만 문제는 이 도구를 사용할 때 거대한 코드 블록 생성을 방지하는 방법입니다. 그러한 유산을 유지하는 데 드는 비용은 매년 점점 더 높아질 것입니다. 

Maxim은 자동화 및 개발 단순화를 목표로 코드 배치 패턴이 어떻게 작동하는지 보여줍니다.

하나 더 보고 우리는 인프라에 대해 듣게 될 것입니다 플레이키(Playkey)의 블라디미르 랴보프(Vladimir Ryabov). 여기서는 인프라 플랫폼에 대해 이야기하고 다음 내용을 학습합니다.

• 저장 공간이 효과적으로 사용되고 있는지 이해하는 방법
• 10TB의 스토리지만 사용하는 경우 어떻게 수백 명의 사용자가 20TB의 콘텐츠를 받을 수 있습니까?
• 데이터를 5배로 압축하여 실시간으로 사용자에게 제공하는 방법;
• 여러 데이터 센터 간에 즉시 데이터를 동기화하는 방법
• 하나의 가상 머신을 순차적으로 사용할 때 사용자가 서로에게 미치는 영향을 제거하는 방법.

이 마법의 비밀은 기술이다 FreeBSD용 ZFS 그리고 신선한 포크 Linux의 ZFS. Vladimir는 Playkey의 사례를 공유합니다.

Amixr.IO의 Matvey Kukuy 인생의 예를 들어 준비 말하다, 뭐 SRE 안정적인 시스템을 구축하는 데 어떻게 도움이 되는지 알아보세요. Amixr.IO는 백엔드를 통해 클라이언트 사고를 전달하며, 전 세계 수십 개의 근무 팀이 이미 150만 건의 사례를 처리했습니다. 이번 컨퍼런스에서 Matvey는 회사가 고객 문제 해결 및 실패 분석을 통해 축적한 통계와 통찰력을 공유할 예정입니다.

다시 한 번 욕심을 부리지 말고 DevOps 사무라이로서의 경험을 공유할 것을 촉구합니다. 제공하다 의뢰 보고서를 위해 당신과 나는 훌륭한 연설을 준비하는 데 2,5개월의 시간을 갖게 될 것입니다. 청취자가 되고 싶다면, 구독 프로그램 업데이트가 포함된 뉴스레터를 확인하고, 컨퍼런스 날짜가 가까워질수록 티켓 가격이 더 비싸질 수 있으므로 미리 티켓을 예약하는 것에 대해 진지하게 생각해 보세요.

출처 : habr.com