프로덕션에서 테스트: Canary 배포

카나리아는 끊임없이 노래하는 작은 새입니다. 이 새들은 메탄과 일산화탄소에 민감합니다. 공기 중에 과도한 가스가 조금만 농도되어도 의식을 잃거나 죽을 수 있습니다. 금광 탐사자들과 광부들은 새들을 데리고 채굴을 했습니다. 카나리아가 노래하는 동안 그들은 일할 수 있었습니다. 만약 그들이 조용해진다면 광산에 가스가 있다는 뜻이고, 떠나야 할 때라는 뜻입니다. 광부들은 광산에서 살아 나오기 위해 작은 새를 희생했습니다.

이와 비슷한 관행이 IT 분야에도 적용되었습니다. 예를 들어, 사전 테스트를 거쳐 새로운 버전의 서비스나 애플리케이션을 프로덕션에 배포하는 표준 작업이 있습니다. 테스트 환경이 너무 비쌀 수 있고, 자동화된 테스트로는 원하는 모든 것을 다룰 수 없으며, 테스트를 하지 않고 품질을 희생하는 것은 위험합니다. 여기서 Canary 배포 방식이 유용합니다. 실제 프로덕션 트래픽의 일부를 새 버전으로 전송하는 방식입니다. 접근 방식이 도움이 됩니다 안전하게 새 버전 확인 생산을 위해, 큰 목표를 위해 작은 것을 희생하는 것. 더 자세히 말하면 접근 방식이 어떻게 작동하는지, 무엇이 유용한지, 어떻게 구현하는지 알려드리겠습니다. 안드레이 마르켈로프 (안드레이_V_마르켈로프), Infobip 회사의 구현 사례를 사용합니다.

안드레이 마르켈로프 — Infobip의 수석 소프트웨어 엔지니어로 11년간 금융 및 통신 분야에서 Java 애플리케이션을 개발해 왔습니다. 오픈 소스 제품을 개발하고, Atlassian 커뮤니티에 적극적으로 참여하며, Atlassian 제품용 플러그인을 작성합니다. 프로메테우스, 도커, 레디스 전도사.

인포빕 소개

은행, 소매업체, 온라인 상점, 운송 회사가 SMS, 푸시, 이메일, 음성 메시지를 사용하여 고객에게 메시지를 보낼 수 있도록 하는 글로벌 통신 플랫폼입니다. 이러한 사업에서는 고객이 제때 메시지를 받을 수 있도록 안정성과 신뢰성이 중요합니다.

Infobip IT 인프라를 수치로 표현한 내용:

• 전 세계에 15개의 데이터 센터
• 500개의 고유한 서비스가 운영 중입니다.
• 2500개의 서비스 인스턴스는 명령보다 훨씬 많습니다.
• 월간 트래픽 4,5TB
• 4,5억 개의 전화번호

사업이 성장하면서 출시되는 제품 수도 늘어났습니다. 우리는 진행하고 있습니다 하루 60개 릴리스고객들은 더 많은 선택권과 성능을 원하기 때문입니다. 하지만 어려운 점은 서비스는 많은데 팀은 적다는 것입니다. 오류 없이 운영 환경에서 작동할 수 있는 코드를 빠르게 작성해야 합니다.

릴리스

우리의 일반적인 릴리스는 다음과 같습니다. 예를 들어, 서비스 A, B, C, D, E가 있으며, 각 서비스는 별도의 팀에서 개발되었습니다.

어느 시점에서 서비스 A의 팀은 새로운 버전을 배포하기로 결정하지만 서비스 B, C, D, E의 팀은 그 사실을 모릅니다. 서비스 A팀이 진행하는 방법에는 두 가지 옵션이 있습니다.

수행할 것입니다 증분 릴리스: 먼저 한 버전을 교체한 다음 두 번째 버전을 교체합니다.

하지만 두 번째 옵션이 있습니다: 팀 추가 용량과 기계를 찾을 수 있습니다, 새로운 버전을 배포한 다음 라우터를 전환하면 해당 버전이 프로덕션에서 작동하게 됩니다.

어떤 경우든 배포 후에는 버전을 테스트했더라도 거의 항상 문제가 발생합니다. 수동으로 테스트할 수도 있고, 자동으로 테스트할 수도 있고, 테스트하지 않아도 됩니다. 어떤 경우든 문제가 발생합니다. 이 문제를 해결하는 가장 쉽고 올바른 방법은 작동하는 버전으로 롤백하는 것입니다. 오직 그때에야 우리는 피해와 원인을 다루고 바로잡을 수 있습니다.

그럼 우리는 무엇을 원하는가?

우리는 문제를 원하지 않아요. 만약 고객이 우리보다 먼저 이를 발견한다면, 우리 회사의 평판이 손상될 것입니다. 그래서 우리는해야합니다 고객보다 더 빠르게 문제를 발견하다. 사전에 적극적으로 대응함으로써 피해를 최소화합니다.

동시에 우리는 원한다 배포 속도를 높이다그래서 이 일이 팀의 스트레스 없이 빠르고, 쉽고, 자연스럽게 일어날 수 있습니다. 엔지니어, DevOps 엔지니어 및 프로그래머는 보호받아야 합니다. 새로운 버전을 출시하는 것은 스트레스가 됩니다. 팀은 소모품이 아닙니다. 우리는 노력합니다. 인적자원을 합리적으로 활용하다.

배포 문제

고객 트래픽은 예측할 수 없습니다. 고객 트래픽이 가장 낮은 시점이 언제인지 예측하는 것은 불가능합니다. 고객이 언제 어디서 캠페인을 시작할지는 알 수 없습니다. 오늘 밤 인도에서 시작될 수도 있고, 내일은 홍콩에서 시작될 수도 있습니다. 시차가 크기 때문에 오전 2시에 배포하더라도 클라이언트가 영향을 받지 않을 것이라는 보장은 없습니다.

제공자의 문제. 메신저와 공급업체는 우리의 파트너입니다. 때로는 새로운 버전을 배포할 때 오류를 일으키는 결함이 있습니다.

분산 팀. 클라이언트와 백엔드를 개발하는 팀은 서로 다른 시간대에 위치해 있습니다. 이 때문에 그들은 종종 서로 합의에 도달하지 못합니다.

데이터 센터는 스테이지에서 복제될 수 없습니다.. 한 데이터 센터에는 200개의 랙이 있는데, 샌드박스에서 이를 추정하는 것조차 불가능합니다.

다운타임용납할 수 없다! 예를 들어, 99,99%의 시간 동안 작업한다면 허용 가능한 가용성 수준(오류 예산)을 갖게 되고, 나머지 비율은 "실수할 권리"입니다. 100%의 안정성을 달성하는 것은 불가능하지만, 충돌과 가동 중지를 지속적으로 모니터링하는 것이 중요합니다.

클래식 솔루션

버그 없이 코드를 작성하세요. 제가 젊은 개발자였을 때는 관리자가 찾아와 버그 없이 출시해 달라고 부탁하곤 했지만, 항상 그렇게 할 수 있는 것은 아니었습니다.

테스트 작성. 테스트는 효과가 있지만 때로는 회사가 원하는 방식으로 이루어지지 않을 수도 있습니다. 테스트의 목적은 돈을 버는 것이 아닙니다.

무대 테스트. Infobip에서 3,5년 반 동안 일하면서 무대의 상태가 제작과 일부라도 일치하는 것을 본 적이 없습니다.

우리는 심지어 이 아이디어를 발전시키려고 노력했습니다. 먼저 무대를 만들고, 그다음 사전 제작을 하고, 그다음 사전 제작의 사전 제작을 했습니다. 하지만 그것도 도움이 되지 않았습니다. 그들은 힘에서도 상대가 되지 못했습니다. 스테이지를 사용하면 기본적인 기능은 보장할 수 있지만, 부하가 걸릴 때 어떻게 작동할지 알 수 없습니다.

해당 릴리스는 해당 릴리스를 개발한 사람에 의해 실행됩니다. 좋은 관행입니다. 누군가 댓글 이름을 변경하더라도 프로덕션에 즉시 추가됩니다. 이는 책임감을 키우고 발생한 변화를 기억하는 데 도움이 됩니다.

추가적인 합병증도 있습니다. 개발자가 모든 것을 수동으로 확인하는 데 많은 시간을 들이는 것은 스트레스가 됩니다.

조정된 릴리스. 이 옵션은 일반적으로 경영진이 제안합니다. "매일 새로운 버전을 테스트하고 추가하는 데 동의합시다." 이 방법은 효과가 없습니다. 항상 다른 사람을 기다리는 팀이 있거나, 그 반대의 경우도 마찬가지입니다.

연기 테스트

배포 문제를 해결하는 또 다른 방법입니다. 팀 A가 새로운 버전을 배포하려고 할 때의 이전 예를 사용하여 스모크 테스트가 어떻게 작동하는지 살펴보겠습니다.

먼저, 팀은 하나의 인스턴스를 프로덕션에 배포합니다. 모의 인스턴스에 대한 메시지 실제 교통 상황을 시뮬레이션합니다일상적인 교통과 일치하도록 합니다. 모든 것이 원활하게 진행된다면, 팀은 새로운 버전을 사용자 트래픽으로 전환할 것입니다.

두 번째 옵션은 배포하는 것입니다 추가 철분 함유. 팀은 이를 프로덕션 환경에서 테스트한 후, 다시 전환하여 모든 것이 제대로 작동합니다.

연기 테스트의 단점:

• 테스트는 신뢰할 수 없습니다. 프로덕션과 동일한 트래픽을 어디서 얻을 수 있나요? 어제나 일주일 전의 데이터를 사용할 수 있지만, 항상 현재 데이터와 일치하는 것은 아닙니다.
• 유지하기 어렵다. 테스트 계정을 유지 관리하고, 활성 레코드가 저장소로 전송될 때마다 배포 전에 계정을 지속적으로 재설정해야 합니다. 샌드박스에서 테스트를 작성하는 것보다 더 어렵습니다.

여기서 유일한 보너스는 성능을 확인할 수 있습니다.

카나리아 릴리스

스모크 테스트의 단점으로 인해 우리는 카나리아 릴리스를 사용하기 시작했습니다.

광부들이 카나리아를 이용해 가스 수치를 측정했던 것과 비슷한 관행이 IT 분야에도 도입되었습니다. 우리는 들여보내고 있습니다 새 버전에 대한 실제 프로덕션 트래픽SLA(서비스 수준 계약)를 충족하려고 노력하는 동안. SLA는 우리가 1년에 한 번(또는 다른 기간 동안) 사용할 수 있는 "실수를 할 권리"입니다. 모든 것이 잘 진행된다면, 더 많은 트래픽을 추가할 것입니다. 그렇지 않은 경우 이전 버전으로 돌아갑니다.

구현 및 뉘앙스

카나리아 릴리스를 어떻게 구현했나요? 예를 들어, 여러 클라이언트가 우리 서비스를 통해 메시지를 보냅니다.

배포는 다음과 같습니다. 밸런서에서 하나의 노드를 제거하고(1), 버전을 변경하고(2) 별도로 약간의 트래픽을 시작합니다(3).

전반적으로, 사용자 한 명이 불만족스러워하더라도 그룹 내 모든 구성원이 행복할 것입니다. 모든 것이 괜찮다면, 우리는 모든 버전을 바꿉니다.

대부분의 경우 마이크로서비스에서 이것이 어떻게 나타나는지 개략적으로 보여드리겠습니다.

서비스 검색과 S1N1, S2라는 두 가지 서비스가 더 있습니다. 첫 번째 서비스(S1N1)는 시작 시 Service Discovery에 알리고, Service Discovery는 이를 기억합니다. 두 개의 노드(S2N1 및 S2N2)가 있는 두 번째 서비스도 시작 시 서비스 검색에 알립니다.

두 번째 서비스는 첫 번째 서비스의 서버 역할을 합니다. 첫 번째는 서비스 검색에서 서버에 대한 정보를 요청하고, 정보를 받으면 서버를 검색하여 점검합니다("상태 점검"). 그가 확인하면 그들에게 메시지를 보낼 것이다.

누군가가 두 번째 서비스의 새로운 버전을 배포하고 싶을 때, Service Discovery에 두 번째 노드가 카나리아 노드가 될 것이라고 알려줍니다. 배포가 곧 시작되기 때문에 트래픽이 줄어듭니다. 밸런서 아래에서 카나리아 노드를 제거하면 첫 번째 서비스는 해당 노드로 트래픽을 전송하지 않습니다.

버전을 변경하면 Service Discovery에서 두 번째 노드가 이제 카나리아라는 것을 알게 되므로 부하를 줄일 수 있습니다(5%). 모든 것이 괜찮다면 버전을 변경하고, 로드를 반환하고 작업을 계속합니다.

이 모든 것을 구현하려면 다음이 필요합니다.

• 균형;
• 모니터링각 사용자가 무엇을 기대하는지, 그리고 우리 서비스가 어떻게 자세히 작동하는지 아는 것이 중요하기 때문입니다.
• 버전 분석, 새로운 버전이 실제 운영 환경에서 얼마나 잘 작동할지 파악합니다.
• 오토메이션 — 배포 파이프라인을 작성합니다.

균형

이것이 우리가 가장 먼저 생각해야 할 점입니다. 균형 잡는 전략은 두 가지가 있습니다.

가장 간단한 옵션은 다음과 같습니다. 한 노드는 항상 카나리아입니다. 이 노드는 항상 트래픽이 적기 때문에 여기서부터 배포를 시작합니다. 문제가 발생할 경우 배포 전과 배포 중의 작동을 비교해 보겠습니다. 예를 들어, 오류의 수가 두 배로 늘어나면 피해도 두 배로 늘어납니다.

Canary 노드는 배포 중에 설정됩니다.. 배포가 완료되고 캐나리 노드 상태를 해제하면 트래픽 균형이 복원됩니다. 자동차가 적으면 공평한 분배가 가능합니다.

모니터링

카나리아 방출의 초석. 우리는 왜 이런 일을 하는지, 그리고 어떤 측정 항목을 수집하고 싶은지 정확히 이해해야 합니다.

당사의 서비스를 통해 수집한 지표의 예입니다.

• 오류 수로그에 기록됩니다. 이는 모든 것이 제대로 작동하고 있다는 분명한 표시입니다. 전반적으로 이는 좋은 지표입니다.
• 쿼리 실행 시간 (숨어 있음). 모두가 빠르게 일하고 싶어하기 때문에 모든 사람이 이 지표를 모니터링합니다.
• 대기열 크기 (처리량).
• 초당 성공적인 응답 수.
• 모든 요청의 95%에 대한 실행 시간입니다.
• 사업 지표: 특정 기간 동안 기업이 얼마나 많은 수익을 창출하는지 또는 사용자 이탈률. 이런 측정항목은 엔지니어가 추가한 측정항목보다 새로운 버전에 더 중요할 수 있습니다.

가장 널리 사용되는 모니터링 시스템의 측정 항목 예입니다.

카운터. 예를 들어, 오류의 수가 증가하는 것과 같은 값입니다. 이 지표는 보간하기 쉽고 그래프를 연구하기 쉽습니다. 어제는 오류가 2개였고, 오늘은 500개였는데, 이는 문제가 발생했음을 의미합니다.

분당 또는 초당 오류 수는 Counter를 사용하여 계산할 수 있는 가장 중요한 지표입니다. 이 데이터는 시간 경과에 따른 시스템 성능에 대한 명확한 그림을 제공합니다. 두 가지 버전의 프로덕션 시스템에 대한 초당 오류 수를 나타낸 그래프의 예를 살펴보겠습니다.

첫 번째 버전에는 버그가 거의 없었는데, 아마도 감사가 제대로 작동하지 않았을 것입니다. 두 번째 버전에서는 모든 것이 훨씬 더 나쁩니다. 문제가 있다는 것은 분명하므로 이 버전을 롤백해야 합니다.

계량기. 메트릭은 카운터와 유사하지만 증가하거나 감소할 수 있는 값을 기록합니다. 예를 들어, 쿼리 실행 시간이나 대기열 크기입니다.

그래프는 응답 시간(대기 시간)의 예를 보여줍니다. 그래프를 보면 두 버전이 비슷하고 작업할 수 있다는 것이 분명합니다. 하지만 자세히 살펴보면 크기가 어떻게 변하는지 볼 수 있습니다. 사용자를 추가할 때 쿼리 실행 시간이 증가한다면 문제가 있다는 것을 바로 알 수 있습니다. 이런 일은 이전에 일어난 적이 없습니다.

요약. 사업에 있어서 가장 중요한 지표 중 하나가 백분위수입니다. 이 지표는 다음을 보여줍니다. 95%의 경우 우리의 시스템은 우리가 원하는 대로 작동합니다. 우리는 모든 것이 얼마나 좋고 나쁜지에 대한 일반적인 추세를 이해하기 때문에 어딘가에 문제가 있다는 것을 받아들일 수 있습니다.

도구

ELK 스택. Elasticsearch를 사용하여 카나리아를 구현할 수 있습니다. 이벤트가 발생하면 카나리아에 오류를 기록합니다. 간단한 API 호출을 통해 특정 시점의 오류 수를 알아내고 이전 기간과 비교할 수 있습니다. GET /applg/_cunt?q=level:errr.

프로 메테우스. Infobip에서 좋은 성과를 거두었습니다. 레이블을 사용하므로 다차원 측정 항목을 구현할 수 있습니다.

우리는 사용할 수 있습니다 level, instance, service, 이들을 하나의 시스템으로 결합합니다. 의 도움으로 offset 예를 들어, 단 하나의 명령으로 일주일 전 수량의 값을 볼 수 있습니다. GET /api/v1/query?query={query}어디에서 {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

버전 분석

버전 분석에는 여러 가지 전략이 있습니다.

카나리아 노드에 대한 메트릭만 봅니다. 가장 간단한 옵션 중 하나는 새로운 버전을 배포하고 작동 방식을 연구하는 것입니다. 하지만 이때 엔지니어가 로그를 연구하고, 끊임없이 불안하게 페이지를 다시 로드하기 시작한다면, 이 솔루션은 다른 솔루션과 다르지 않습니다.

캐나리 노드는 다른 노드와 비교됩니다.. 이는 최대 트래픽으로 실행 중인 다른 인스턴스와 비교한 것입니다. 예를 들어, 트래픽이 적을 때 상황이 실제 인스턴스보다 더 나쁘거나 나아지지 않는다면 뭔가 문제가 있는 것입니다.

카나리아 노드는 과거의 자신과 비교됩니다. 카나리아에 할당된 노드는 과거 데이터와 비교할 수 있습니다. 예를 들어, 일주일 전까지만 해도 모든 것이 괜찮았다면 이 데이터를 사용하여 현재 상황을 파악할 수 있습니다.

오토메이션

엔지니어가 수동 비교에 얽매이지 않도록 하기 위해 자동화를 구현하는 것이 중요합니다. 배포 파이프라인은 일반적으로 다음과 같습니다.

• 시작하자;
• 밸런서 아래에서 노드를 제거합니다.
• 카나리아 노드를 설치합니다.
• 우리는 제한된 양의 교통량으로 밸런서를 켭니다.
• 비교.

이 단계에서 우리는 다음을 구현합니다. 자동 비교. Jenkins의 예를 사용하여 배포 후에 확인하는 것보다 어떤 모습일지, 그리고 왜 더 나은지 살펴보겠습니다.

이것은 Groovy로 가는 파이프라인입니다.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

여기 사이클에서 우리는 한 시간 내에 새로운 노드를 비교할 것이라고 지정합니다. 카나리아 프로세스가 아직 완료되지 않았다면 함수를 호출합니다. 그녀는 모든 것이 좋은지 나쁜지 말해줍니다. def isOk = compare(srv, canary, time, base, offset, metrics).

모든 것이 좋다면 - sleep DEFAULT SLEEP예를 들어, 잠깐 멈추고 계속하세요. 그렇지 않으면 종료합니다. 배포가 실패했습니다.

지표에 대한 설명입니다. 함수가 어떻게 생겼는지 살펴보겠습니다. compare DSL을 예로 들어 보겠습니다.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

오류 수를 비교하고 지난 5분 동안 초당 오류 수를 알고 싶다고 가정해 보겠습니다.

두 가지 값이 있습니다. 기본 노드와 카나리아 노드입니다. 카나리아 노드의 값은 현재입니다. 기초적인 - baseValue — 이는 다른 모든 비 카나리 노드의 값입니다. 우리는 경험과 관찰을 바탕으로 정한 공식을 사용해 값을 서로 비교합니다. 값이 canaryValue 나쁘면 배포에 실패하고 롤백합니다.

왜 이 모든 것이 필요한가요?

사람은 수백, 수천 개의 지표를 확인할 수 없습니다.특히 빠르게 하기 위해서요. 자동 비교를 통해 모든 지표를 확인하고 문제가 발생하면 신속하게 알림을 받을 수 있습니다. 알림 시간은 매우 중요합니다. 지난 2초 동안 무슨 일이 발생하더라도 15분 전에 발생한 일보다 피해가 크지 않을 것입니다. 누군가 문제를 알아차리고 지원팀에 글을 쓰고 지원팀에서 문제를 해결해야 할 때쯤이면 고객을 잃을 수도 있습니다.

프로세스가 성공적이고 모든 것이 괜찮으면 다른 모든 노드를 자동으로 배포합니다. 이 기간 동안 엔지니어는 아무것도 하지 않습니다. 카나리아를 출시한 후에야 어떤 지표를 사용할지, 비교에 얼마나 오랜 시간을 할애할지, 어떤 전략을 사용할지 결정합니다.

문제가 발생하면 자동으로 카나리아 노드를 롤백하고, 이전 버전에서 작업하고 발견된 오류를 수정합니다. 지표를 사용하면 쉽게 찾을 수 있고, 새 버전으로 인한 피해도 확인할 수 있습니다.

장애물

물론, 이를 구현하는 것은 쉽지 않습니다. 우선적으로 필요한 것은 일반 모니터링 시스템. 엔지니어는 자체 지표를 갖고, 지원 및 분석가는 다른 지표를 갖고, 기업은 세 번째 지표를 갖습니다. 공통 시스템은 기업과 개발 분야에서 사용하는 공통 언어입니다.

실제로 테스트해봐야겠다 지표의 안정성. 확인하면 이해하는 데 도움이 됩니다. 품질을 보장하는 데 필요한 최소한의 측정 항목은 무엇입니까?.

이것을 달성하는 방법? 배포 시점에 카나리아 서비스를 사용하지 마십시오.. 우리는 언제든지 전용 노드를 이용할 수 있고 배포 없이도 트래픽을 줄일 수 있는 서비스를 이전 버전에 추가했습니다. 그런 다음 우리는 비교합니다. 실수를 연구하고 품질을 달성할 수 있는 지점을 찾습니다.

카나리아 릴리스로 얻은 이점

벌레로 인한 피해 비율을 최소화했습니다. 대부분의 배포 오류는 일부 데이터 또는 우선순위 불일치로 인해 발생합니다. 이런 오류는 처음 몇 초 안에 문제를 해결할 수 있기 때문에 훨씬 적습니다.

팀의 업무를 최적화했습니다. 초보자는 "실수를 할 권리"를 갖습니다. 실수를 두려워하지 않고 프로덕션에 배포할 수 있으며, 작업에 대한 주도성과 인센티브가 추가로 제공됩니다. 뭔가를 망가뜨린다고 해도 중요한 문제는 아닐 것이고, 실수를 저지른 사람이 해고되지도 않을 것입니다.

자동화된 배포. 이는 이전처럼 수동적인 과정이 아니라 완전히 자동화된 과정입니다. 하지만 시간이 더 오래 걸립니다.

중요한 지표 강조. 사업부터 엔지니어링까지 회사 전체가 우리 제품에서 무엇이 정말 중요한지, 예를 들어 사용자 이탈과 유입과 같은 측정 항목이 무엇인지 알고 있습니다. 우리는 프로세스를 제어합니다. 측정 항목을 테스트하고, 새로운 측정 항목을 도입하고, 기존 측정 항목이 어떻게 작동하는지 확인하여 더 효율적으로 수익을 창출할 수 있는 시스템을 구축합니다.

우리에게는 도움이 되는 훌륭한 관행과 시스템이 많이 있습니다. 그럼에도 불구하고, 우리는 우리에게 도움이 될 시스템이 있는지 없는지에 관계 없이 전문가로서 최선을 다하고 업무를 잘 수행하기 위해 노력합니다.

엔지니어링 접근 방식 및 관행 - TechLead Conf 컨퍼런스의 주요 초점. 기술적 우수성을 향한 길에서 성공을 이루었고 이를 달성하는 데 도움이 된 사항을 알려주실 준비가 되셨다면, 보고서를 신청하다.

우리는 개최할 계획입니다 기술 리드 회의 8월 XNUMX일. 우리는 지금 당장 컨퍼런스 참여에 대한 결정을 내리기 어렵다는 것을 알고 있습니다. 하지만 동시에 우리는 격리가 전문적인 의사소통과 개발을 멈추는 이유가 되어서는 안 된다고 믿습니다. 따라서 어떤 경우든 우리는 기술 책임자의 업무와 이를 해결하기 위한 접근 방식을 논의할 방법을 찾을 것입니다. 필요하다면 온라인에 접속하여 네트워킹을 구축할 것입니다!

출처 : habr.com