CTO의 역량은 그가 이 역할을 두 번째로 수행할 때만 테스트되는 것으로 알려져 있습니다. 한 회사에서 몇 년 동안 일하면서 함께 발전하고, 같은 문화적 맥락에서 점차 더 많은 책임을 맡는 것이 하나의 일이기 때문입니다. 그리고 레거시 짐과 깔개 아래 깔끔하게 휩쓸린 많은 문제가 있는 회사의 기술 이사 직책을 곧바로 맡는 것은 또 다른 일입니다.

이런 의미에서 그가 공유한 Leon Fire의 경험은 다음과 같습니다. DevOpsConf, 정확히 독특하지는 않지만 그의 경험과 그가 20년 동안 시도한 다양한 역할의 수를 곱하면 매우 유용합니다. 컷 아래에는 90일에 걸쳐 일어난 사건들의 연대기와, 남에게 일어났을 때 웃으면 재미있지만 직접 만나면 별로 재미가 없는 수많은 이야기들이 담겨 있다.

레온은 러시아어를 매우 다채롭게 구사하므로 35~40분 정도 시간이 있으시면 영상을 시청하시는 것을 추천드립니다. 아래는 시간을 절약하기 위한 텍스트 버전입니다.

보고서의 첫 번째 버전은 유용한 권장 사항을 포함하여 인력 및 프로세스 작업에 대한 잘 구조화된 설명이었습니다. 그러나 그녀는 그 과정에서 겪은 놀라움을 모두 전달하지 않았습니다. 그래서 포맷을 바꿔서 새 회사에서 잭인더박스처럼 눈앞에 떠오른 문제와 그 해결 방법을 시간순으로 제시했다.

한 달 전

많은 좋은 이야기처럼 이 이야기도 술에서 시작되었습니다. 우리는 친구들과 함께 술집에 앉아 있었는데, IT 전문가들 사이에서도 역시 다들 자신들의 문제에 대해 울고 있었습니다. 그들 중 한 명은 방금 직장을 바꾸었고 기술, 사람, 팀과 관련된 자신의 문제에 대해 이야기하고 있었습니다. 더 많이 들을수록 그가 나를 고용해야 한다는 것을 더 많이 깨달았습니다. 왜냐하면 이것이 제가 지난 15년 동안 해결해 왔던 문제 유형이기 때문입니다. 나는 그에게 그렇게 말했고, 다음날 우리는 직장에서 만났습니다. 이 회사는 Teaching Strategies라고 불렸습니다.

Teaching Strategies는 출생부터 40세까지의 아주 어린 아이들을 위한 커리큘럼 분야의 시장 선두주자입니다. 전통적인 "종이" 회사는 이미 10년이 되었고, 플랫폼의 디지털 SaaS 버전은 2017년이 되었으며, 비교적 최근에 디지털 기술을 회사 표준에 적용하는 프로세스가 시작되었습니다. XNUMX년에 출시된 "새" 버전은 이전 버전과 거의 비슷했지만 작동이 더 나빴습니다.

가장 흥미로운 점은 이 회사의 트래픽이 매우 예측 가능하다는 것입니다. 매일, 해마다 얼마나 많은 사람들이 언제 올 것인지 매우 명확하게 예측할 수 있습니다. 예를 들어, 오후 13시에서 15시 사이에 유치원의 모든 어린이는 잠자리에 들고 교사는 정보를 입력하기 시작합니다. 주말에는 일하는 사람이 거의 없기 때문에 이런 일은 주말을 제외하고 매일 발생합니다.

조금 앞을 내다보면 연간 트래픽이 가장 많은 기간에 작업을 시작했다는 점을 알 수 있는데, 이는 여러 가지 이유로 흥미롭습니다.

2년밖에 안 된 것 같았던 이 플랫폼에는 2008년부터 ColdFusion과 SQL Server라는 독특한 스택이 있었습니다. ColdFusion은 모르신다면 아마 모르실 겁니다. 90년대 중반에 나온 기업용 PHP인데 그 이후로는 들어본 적도 없습니다. 또한 Ruby, MySQL, PostgreSQL, Java, Go, Python도 있었습니다. 그러나 주요 모놀리스는 ColdFusion과 SQL Server에서 실행되었습니다.

문제

회사 직원들과 업무에 대해, 어떤 문제가 발생했는지에 대해 이야기를 나눌수록 그 문제는 기술적인 문제만이 아니라는 것을 깨닫게 되었습니다. 기술은 오래되었고 작동하지 않았지만 팀과 프로세스에 문제가 있었고 회사는 이를 이해하기 시작했습니다.

전통적으로 기술자들은 구석에 앉아 일종의 작업을 수행했습니다. 그러나 점점 더 많은 비즈니스가 디지털 버전을 거치기 시작했습니다. 그래서 제가 일을 시작하기 전 작년에 이사회, CTO, CPO 및 QA 이사 등 새로운 사람이 회사에 나타났습니다. 즉, 회사는 기술 부문에 투자하기 시작했습니다.

무거운 유산의 흔적은 시스템에만 있는 것이 아닙니다. 회사에는 레거시 프로세스, 레거시 인력, 레거시 문화가 있었습니다. 이 모든 것이 바뀌어야 했습니다. 분명 지루하지 않을 거라 생각하고 한번 시도해 보기로 했습니다.

이틀 전

새 일을 시작하기 이틀 전 사무실에 도착해 마지막 서류를 작성하고 팀을 만났는데 당시 팀이 문제로 어려움을 겪고 있다는 사실을 알게 됐다. 평균 페이지 로딩 시간이 4초, 즉 2배로 뛴 셈이다.

그래프로 판단하면 분명히 무슨 일이 일어났고, 무엇인지는 확실하지 않습니다. 문제는 데이터 센터의 네트워크 대기 시간인 것으로 밝혀졌습니다. 데이터 센터의 5ms 대기 시간이 사용자에게는 2초로 바뀌었습니다. 왜 이런 일이 일어났는지는 모르겠지만 어쨌든 데이터센터에 문제가 있다는 사실이 알려졌습니다.

첫날

이틀이 지났고 근무 첫날에 문제가 사라지지 않았다는 것을 알게 되었습니다.

이틀 동안 사용자의 페이지는 평균 4초 만에 로드되었습니다. 문제가 무엇인지 찾았는지 묻습니다.

- 네, 티켓을 열었습니다.
- 그리고?
- 글쎄요, 아직 답변이 없어요.

그러다가 나는 이전에 내가 들었던 모든 것이 내가 싸워야 할 빙산의 작은 일각에 불과하다는 것을 깨달았습니다.

이에 아주 잘 어울리는 좋은 인용문이 있습니다:

“때때로 기술을 바꾸려면 조직을 바꿔야 합니다.”

하지만 일년 중 가장 바쁜 시기에 일을 시작했기 때문에 문제 해결을 위해 빠른 방법과 장기적인 방법, 두 가지 옵션을 모두 살펴봐야 했습니다. 그리고 지금 당장 중요한 것부터 시작하세요.

하루에 세번

따라서 로딩은 4초 동안 지속되며 13~15가 가장 큰 피크입니다.

이 기간 동안 셋째 날 다운로드 속도는 다음과 같았습니다.

내 관점에서는 전혀 효과가 없었습니다. 다른 사람들의 관점에서 보면 평소보다 조금 느리게 진행되고 있었습니다. 하지만 그런 일은 일어나지 않습니다. 심각한 문제입니다.

나는 팀을 설득하려고 노력했고 팀은 단순히 서버가 더 필요하다고 대답했습니다. 물론 이것은 문제에 대한 해결책이지만 항상 유일하고 가장 효과적인 것은 아닙니다. 서버가 부족한 이유와 트래픽 양이 어느 정도인지 물었습니다. 데이터를 추정한 결과 초당 약 150개의 요청이 있다는 사실을 발견했습니다. 이는 원칙적으로 합리적인 한도 내에 속합니다.

하지만 올바른 답을 얻기 전에 먼저 올바른 질문을 해야 한다는 사실을 잊어서는 안 됩니다. 다음 질문은 '우리가 보유한 프런트엔드 서버는 몇 개입니까?'였습니다. 그 대답은 "약간 당황스러웠습니다"였습니다. 우리는 17개의 프런트엔드 서버를 가지고 있었습니다!

—부끄럽지만 150을 17로 나누면 8정도 되나요? 각 서버가 초당 8개의 요청을 허용하는데, 내일 초당 160개의 요청이 있다면 2개의 서버가 더 필요하다는 말씀이신가요?

물론 추가 서버는 필요하지 않았습니다. 해결책은 코드 자체와 표면에 있었습니다.

var currentClass = classes.getCurrentClass();
return currentClass;

기능이 있었네요 getCurrentClass(), 사이트의 모든 것이 클래스의 맥락에서 작동하기 때문입니다. 맞습니다. 그리고 각 페이지에는 이 하나의 기능이 있었습니다. 200개 이상의 요청.

이 방법의 해결책은 매우 간단했습니다. 아무것도 다시 작성할 필요도 없었습니다. 동일한 정보를 다시 요청하지 마세요.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

나는 단지 XNUMX일 만에 주요 문제를 발견했다고 결정했기 때문에 매우 기뻤습니다. 나는 순진했지만 이것은 많은 문제 중 하나에 불과했습니다.

그러나 이 첫 번째 문제를 해결하면 그래프가 훨씬 더 낮아졌습니다.

동시에 우리는 다른 최적화도 수행했습니다. 고칠 수 있는 부분이 많이 보였습니다. 예를 들어, 같은 XNUMX일차에 결국 시스템에 캐시가 있다는 사실을 발견했습니다(처음에는 모든 요청이 데이터베이스에서 직접 오는 것으로 생각했습니다). 캐시라고 하면 표준 Redis나 Memcached가 떠오릅니다. 하지만 그렇게 생각한 사람은 저뿐이었습니다. 그 시스템이 방금 데이터를 읽은 것과 동일한 캐싱을 위해 MongoDB와 SQL Server를 사용했기 때문입니다.

XNUMX일차

첫 주에는 지금 당장 해결해야 할 문제를 다루었습니다. 두 번째 주쯤에 처음으로 스탠드업에 와서 팀과 소통하고, 무슨 일이 일어나고 있는지, 전체 과정이 어떻게 진행되는지 확인했습니다.

또 흥미로운 사실이 발견되었습니다. 팀은 다음과 같이 구성되었습니다: 개발자 18명; 테스터 8명; 관리자 3명 건축가 2명. 그리고 그들은 모두 공통 의식에 참여했습니다. 즉, 매일 아침 30명이 넘는 사람들이 스탠드업에 와서 자신들이 한 일을 이야기했습니다. 회의에는 5~15분도 걸리지 않은 것이 분명합니다. 모두가 서로 다른 시스템에서 작업하기 때문에 누구도 다른 사람의 말을 듣지 않았습니다. 이 형태에서는 그루밍 세션에 대해 시간당 2-3장의 티켓이 이미 좋은 결과였습니다.

우리가 가장 먼저 한 일은 팀을 여러 제품 라인으로 나누는 것이었습니다. 다양한 섹션과 시스템에 대해 우리는 개발자, 테스터, 제품 관리자, 비즈니스 분석가를 포함하는 별도의 팀을 할당했습니다.

결과적으로 우리는 다음을 얻었습니다:

• 스탠드업과 집회를 줄입니다.
• 제품에 대한 주제 지식.
• 주인의식. 사람들은 항상 시스템을 만지작거릴 때 자신이 아닌 다른 사람이 버그를 해결해야 할 가능성이 높다는 것을 알고 있었습니다.
• 그룹 간 협업. 말할 필요도 없이 이전에는 QA가 프로그래머와 많이 소통하지 않았고, 제품이 자체적으로 작업을 수행했습니다. 이제 그들은 공통의 책임을 갖게 되었습니다.

우리는 주로 효율성, 생산성 및 품질에 중점을 두었습니다. 이는 팀 변화를 통해 해결하려고 노력한 문제입니다.

XNUMX일차

팀 구조를 변경하는 과정에서 카운트 방법을 발견했습니다. 이야기포인트. 1SP는 2일에 해당하며, 각 티켓에는 개발 및 QA를 위한 SP, 즉 최소 XNUMXSP가 포함되어 있습니다.

내가 이것을 어떻게 발견했는가?

버그를 발견했습니다. 보고서 중 하나에서 보고서가 필요한 기간의 시작 날짜와 종료 날짜를 입력하면 마지막 날이 고려되지 않습니다. 즉, 요청 어딘가에 <=가 아니라 단순히 <가 있었습니다. 이것이 XNUMX개의 스토리 포인트라고 들었습니다. 3 일.

그 후 우리는:

• 스토리 포인트 등급 시스템이 개편되었습니다. 이제 시스템을 통해 빠르게 전달될 수 있는 사소한 버그에 대한 수정 사항이 사용자에게 더 빠르게 전달됩니다.
• 개발 및 테스트를 위해 관련 티켓을 병합하기 시작했습니다. 이전에는 모든 티켓, 모든 버그가 다른 어떤 것과도 연결되지 않은 폐쇄된 생태계였습니다. 한 페이지에서 세 개의 버튼을 변경하는 것은 페이지당 하나의 자동화된 테스트 대신 세 개의 서로 다른 QA 프로세스를 사용하는 세 개의 서로 다른 티켓이 될 수 있습니다.
• 우리는 인건비 추정에 대한 접근 방식을 개발자와 협력하기 시작했습니다. 버튼 하나 바꾸는 데 XNUMX일이 걸리는 건 재미없잖아요.

XNUMX일째

첫 달 중순 쯤 상황이 조금 안정되었고 기본적으로 무슨 일이 일어나고 있는지 파악하고 이미 미래를 내다보고 장기적인 해결책을 생각하기 시작했습니다.

장기 목표:

• 관리형 플랫폼. 각 페이지에 수백 건의 요청이 심각한 것은 아닙니다.
• 예측 가능한 추세. 언뜻 보기에는 다른 지표와 상관관계가 없는 주기적인 트래픽 피크가 있었습니다. 우리는 이러한 일이 발생한 이유를 이해하고 예측하는 방법을 배워야 했습니다.
• 플랫폼 확장. 비즈니스는 지속적으로 성장하고 있으며 점점 더 많은 사용자가 찾아오고 트래픽도 증가하고 있습니다.

예전에는 이런 말을 자주 했습니다. "[언어/프레임워크]로 모든 것을 다시 작성하면 모든 것이 더 잘 작동할 것입니다!"

대부분의 경우 이는 작동하지 않습니다. 다시 작성이 작동하면 좋습니다. 따라서 우리는 비즈니스 목표를 달성하는 방법(무엇을 수행할 것인지, 왜 수행할 것인지)을 단계별로 설명하는 구체적인 전략인 로드맵을 작성해야 했습니다.

• 프로젝트의 사명과 목표를 반영합니다.
• 주요 목표의 우선순위를 정합니다.
• 이를 달성하기 위한 일정이 포함되어 있습니다.

이전에는 변경 사항의 목적에 대해 팀에 이야기한 사람이 아무도 없었습니다. 이를 위해서는 올바른 성공 지표가 필요합니다. 회사 역사상 처음으로 기술 그룹에 대한 KPI를 설정했으며 이러한 지표는 조직의 지표와 연결되었습니다.

즉, 조직 KPI는 팀에서 지원되고 팀 KPI는 개별 KPI에서 지원됩니다. 그렇지 않고 기술 KPI가 조직 KPI와 일치하지 않으면 모든 사람이 스스로 책임을 지게 됩니다.

예를 들어 조직의 KPI 중 하나는 신제품을 통해 시장 점유율을 높이는 것입니다.

더 많은 신제품을 출시하려는 목표를 어떻게 지원할 수 있나요?

• 첫째, 결함을 고치는 것보다 신제품 개발에 더 많은 시간을 투자하고 싶습니다. 이는 측정하기 쉬운 논리적 솔루션입니다.
• 둘째, 시장 점유율이 높을수록 사용자가 많아지고 이에 따라 트래픽도 많아지기 때문에 거래량 증가를 지원하고 싶습니다.

그러면 그룹 내에서 실행할 수 있는 개별 KPI가 주요 결함이 발생한 위치에 있게 됩니다. 이 섹션에 구체적으로 집중하면 결함이 훨씬 줄어드는 것을 확인할 수 있으며, 그러면 신제품을 개발하고 다시 조직 KPI를 지원하는 시간이 늘어납니다.

따라서 코드 재작성을 포함한 모든 결정은 회사가 우리를 위해 설정한 특정 목표(조직 성장, 새로운 기능, 채용)를 뒷받침해야 합니다.

이 과정에서 흥미로운 사실이 밝혀졌고 이는 기술 전문가뿐만 아니라 회사 전반에 걸쳐 뉴스가 되었습니다. 모든 티켓은 최소한 하나의 KPI에 초점을 맞춰야 한다는 것입니다. 즉, 제품이 새로운 기능을 만들고 싶다고 말하면 첫 번째 질문은 "이 기능은 어떤 KPI를 지원합니까?"라는 질문을 던져야 한다는 것입니다. 그렇지 않다면 죄송합니다. 불필요한 기능인 것 같습니다.

XNUMX일째

월말에 저는 또 다른 미묘한 차이를 발견했습니다. 운영팀의 어느 누구도 우리가 고객과 체결한 계약을 본 적이 없다는 것입니다. 연락처를 확인해야 하는 이유가 무엇인지 물을 수도 있습니다.

• 첫째, SLA가 계약서에 명시되어 있기 때문입니다.
• 둘째, SLA는 모두 다릅니다. 각 고객은 자신의 요구 사항을 가지고 있었고 영업 부서는 보지 않고 서명했습니다.

또 다른 흥미로운 뉘앙스는 가장 큰 클라이언트 중 하나와의 계약에 플랫폼에서 지원하는 모든 소프트웨어 버전이 n-1, 즉 최신 버전이 아니라 두 번째 버전이어야 한다고 명시되어 있다는 것입니다.

플랫폼이 1월에 더 이상 지원되지 않는 ColdFusion 및 SQL Server 2008을 기반으로 한다면 우리가 n-XNUMX에서 얼마나 멀리 떨어져 있는지는 분명합니다.

XNUMX일차

두 번째 달 중순쯤에는 앉아서 할 시간이 충분했어요. 가치흐름매핑 전체 프로세스에 대해 완전히. 제품을 만드는 것부터 소비자에게 전달하는 것까지 꼭 거쳐야 할 단계로, 최대한 자세하게 설명해야 합니다.

프로세스를 작은 조각으로 나누고 시간이 너무 많이 걸리는 부분, 최적화하고 개선할 수 있는 부분 등을 확인합니다. 예를 들어, 제품 요청이 그루밍을 거치는 데 걸리는 시간, 개발자가 받을 수 있는 티켓에 언제 도달하는지, QA 등이 있습니다. 그래서 각 단계를 자세히 살펴보고 무엇이 최적화될 수 있는지 생각해 보세요.

이 작업을 수행했을 때 내 눈에 띄는 두 가지 사항은 다음과 같습니다.

• QA에서 개발자에게 반환된 티켓의 비율이 높습니다.
• 끌어오기 요청 검토가 너무 오래 걸렸습니다.

문제는 다음과 같은 결론이 나왔다는 점이다. 시간이 많이 걸릴 것 같은데, 얼마나 걸릴지 모르겠다.

"측정할 수 없는 것은 개선할 수 없습니다."

문제가 얼마나 심각한지 정당화하는 방법은 무엇입니까? 며칠이나 몇 시간을 낭비합니까?

이를 측정하기 위해 Jira 프로세스에 "개발 준비 완료" 및 "QA 준비 완료"라는 몇 가지 단계를 추가하여 각 티켓이 대기하는 시간과 특정 단계로 돌아오는 횟수를 측정했습니다.

또한 검토를 위해 평균적으로 몇 개의 티켓이 있는지 확인하기 위해 "검토 중"을 추가했으며, 여기에서 춤을 출 수 있습니다. 우리는 시스템 측정항목을 갖고 있었지만 이제 새로운 측정항목을 추가하고 측정을 시작했습니다.

• 프로세스 효율성: 성과 및 기획/납품.
• 공정 품질: 결함 수, QA 결함.

무엇이 잘되고 있고 무엇이 잘 안 되고 있는지 이해하는 것은 정말 도움이 됩니다.

XNUMX일째

물론 이것은 모두 좋고 흥미롭지 만 두 번째 달 말에 그러한 규모를 기대하지는 않았지만 원칙적으로 예측 가능한 일이 일어났습니다. 최고 경영진이 바뀌자 사람들이 떠나기 시작했습니다. 새로운 사람들이 경영진에 합류해 모든 것을 바꾸기 시작했고, 기존 사람들은 그만뒀습니다. 그리고 일반적으로 몇 년 된 회사에서는 모두가 친구이고 서로를 알고 있습니다.

이는 예상됐지만 정리해고 규모는 예상외였다. 예를 들어, 일주일 동안 두 명의 팀 리더가 동시에 자발적으로 사직서를 제출했습니다. 그러므로 나는 다른 문제들을 잊어버릴 뿐만 아니라, 오직 한 가지에만 집중해야 했습니다. 팀 만들기. 이것은 해결하기 길고 어려운 문제이지만, 남은 사람들(또는 그들 대부분)을 구하고 싶었기 때문에 처리해야 했습니다. 팀의 사기를 유지하기 위해 사람들이 떠났다는 사실에 어떻게 든 반응해야했습니다.

이론적으로 이는 좋은 일입니다. 팀의 기술을 평가하고 인력을 교체할 수 있는 완전한 위임장을 갖춘 새로운 사람이 들어옵니다. 사실, 여러 가지 이유로 새로운 사람을 영입할 수는 없습니다. 균형은 항상 필요합니다.

• 오래된 것과 새로운 것. 변화할 수 있고 사명을 지지할 수 있는 노인들을 지켜내야 합니다. 하지만 동시에 우리는 새로운 피를 가져와야 합니다. 이에 대해서는 잠시 후에 이야기하겠습니다.
• 경험. 같이 일하고 싶어하는 의욕이 넘치는 좋은 후배들과 이야기를 많이 나눴어요. 그런데 후배들을 응원해주고 멘토 역할을 해줄 선배들이 부족해서 맡지 못했어요. 먼저 정상을 모집하고 그다음에 청년을 모집해야했습니다.
• 당근과 채찍.

올바른 균형이 무엇인지, 어떻게 유지해야 하는지, 얼마나 유지해야 하는지, 얼마나 밀어야 하는지에 대한 질문에 대해서는 좋은 답을 갖고 있지 않습니다. 이는 순전히 개별 프로세스입니다.

XNUMX일째

나는 내가 누구인지 이해하기 위해 팀을 면밀히 살펴보기 시작했고 다시 한번 기억했습니다.

“대부분의 문제는 사람의 문제입니다.”

저는 개발팀과 운영팀 모두에 세 가지 큰 문제가 있다는 것을 발견했습니다.

• 현재 상황에 만족합니다.
• 책임감 부족 - 누구도 사업에 영향을 미치기 위해 공연자의 작업 결과를 가져온 적이 없기 때문입니다.
• 변화에 대한 두려움.

변화는 항상 당신을 익숙한 영역에서 벗어나게 하며, 젊은 사람들일수록 변화의 이유와 방법을 이해하지 못하기 때문에 변화를 더 싫어합니다. 내가 들은 가장 일반적인 대답은 "우리는 그런 일을 해본 적이 없다"이다. 더욱이 그것은 완전히 터무니없는 지점에 도달했습니다. 누군가가 분개하지 않으면 사소한 변화도 일어날 수 없습니다. 그리고 변화가 그들의 업무에 얼마나 많은 영향을 미쳤는지에 관계없이 사람들은 이렇게 말했습니다. “아니요, 왜요? 이건 안 될 거야."

하지만 아무것도 바꾸지 않고는 나아질 수 없습니다.

나는 직원과 완전히 터무니없는 대화를 나눴고 그에게 최적화에 대한 내 아이디어를 말했고 그는 나에게 다음과 같이 말했습니다.
- 아, 작년에 우리가 본 걸 못 보셨군요!
- 그래서?
“지금은 그때보다 훨씬 나아졌어요.”
- 그럼 더 나아질 수는 없나요?
- 왜?

좋은 질문입니다. 왜죠? 마치 예전보다 지금이 더 나아지면 모든 것이 충분히 좋은 것 같습니다. 이는 원칙적으로 절대적으로 정상적인 책임 부족으로 이어집니다. 내가 말했듯이 기술 그룹은 약간 부업이었습니다. 회사는 존재해야 한다고 믿었지만, 누구도 기준을 정하지 않았어. 기술 지원에서는 SLA를 본 적이 없으므로 그룹에서 상당히 "수용 가능한" 내용이었습니다(이 점이 가장 인상 깊었습니다).

• 로딩 12초;
• 각 릴리스마다 5~10분의 가동 중지 시간이 소요됩니다.
• 중요한 문제를 해결하는 데 며칠, 몇 주가 걸립니다.
• 근무 인력 부족 24x7 / 대기 중.

우리가 왜 더 잘하면 안 되는지 묻는 사람은 아무도 없고, 이렇게 될 필요가 없다는 것도 깨닫지 못한 사람도 없습니다.

보너스로 문제가 하나 더 있었습니다. 경험의 부족. 선배들은 떠났고, 남은 젊은 팀은 이전 정권 밑에서 성장하며 그 정권에 중독됐다.

무엇보다도 사람들은 실패하고 무능해 보이는 것을 두려워했습니다. 이는 첫째로 그들이 어떤 상황에서도 도움을 요청하지 않았습니다.. 우리는 그룹으로, 개별적으로 몇 번이나 이야기를 나누었고 저는 “어떻게 해야 할지 모르면 질문하세요”라고 말했습니다. 나는 나 자신에 대해 자신감이 있고 어떤 문제라도 해결할 수 있다는 것을 알고 있지만 시간이 걸릴 것입니다. 그러므로 10분 안에 해결 방법을 아는 사람에게 물어볼 수 있다면 물어보겠습니다. 경험이 적을수록 자신이 무능하다고 간주될 것이라고 생각하기 때문에 질문하기가 더 두렵습니다.

질문에 대한 두려움은 흥미로운 방식으로 나타납니다. 예를 들어, "이 작업은 어떻게 진행되고 있나요?"라고 묻습니다. - "두 시간 남았는데 벌써 끝냈어요." 다음날 다시 물어보면 모든 것이 괜찮다는 대답을 듣습니다. 하지만 한 가지 문제가 있었습니다. 하루가 끝날 때까지는 확실히 준비가 될 것입니다. 또 하루가 지나고 벽에 갇혀 누군가와 대화를 해야 할 때까지 이 일은 계속됩니다. 사람은 문제를 스스로 해결하고 싶어하지만, 스스로 해결하지 않으면 큰 실패가 될 것이라고 믿습니다.

그 이유는 개발자들은 추정치를 부풀렸다. 똑같은 일화인데, 어떤 일을 논의할 때 그런 모습을 보여서 너무 놀랐다. 개발자의 추정에는 개발자가 QA에서 티켓이 반환되는 시간, 오류를 발견할 수 있는 시간, PR에 소요되는 시간, 검토해야 하는 사람들이 소요되는 시간이 포함되어 있다고 들었습니다. 그것은 바쁠 것입니다. 즉, 가능한 모든 것입니다.

둘째, 무능해 보일까봐 두려워하는 사람들 과도하게 분석하다. 정확히 무엇을 해야 하는지 말하면 다음과 같이 시작됩니다. “아니요, 여기서 생각해 보면 어떨까요?” 이런 의미에서 우리 회사는 독특한 것이 아니라 젊은이들의 표준적인 문제입니다.

이에 대해 저는 다음과 같은 관행을 도입했습니다.

• 규칙은 30분입니다. XNUMX분 안에 문제를 해결할 수 없다면 다른 사람에게 도움을 요청하세요. 사람들이 여전히 묻지 않지만 적어도 프로세스는 시작되었기 때문에 성공의 정도는 다양합니다.
• 본질을 제외한 모든 것을 제거하라, 작업 완료 기한을 추정할 때, 즉 코드를 작성하는 데 걸리는 시간만 고려합니다.
• 지속적인 학습 지나치게 분석하는 사람들을 위해. 사람들과 끊임없이 일하는 것뿐입니다.

XNUMX일째

이 모든 일을 하고 있는 동안 예산을 알아낼 시간이었습니다. 물론 우리가 돈을 쓴 곳에서 흥미로운 것들을 많이 발견했습니다. 예를 들어, 우리는 하나의 클라이언트가 사용하는 하나의 FTP 서버가 있는 별도의 데이터 센터에 전체 랙을 보유했습니다. "... 우리는 이사했지만 그는 그대로 머물렀고 우리는 그를 바꾸지 않았습니다." 2년 전이었습니다.

특히 관심을 끄는 것은 클라우드 서비스에 대한 청구서였습니다. 클라우드 요금이 비싼 주된 이유는 개발자들이 생애 처음으로 서버에 무제한으로 액세스할 수 있기 때문이라고 생각합니다. “테스트 서버를 주세요.”라고 물을 필요 없이 스스로 가져갈 수 있습니다. 게다가 개발자들은 항상 Facebook과 Netflix가 부러워할 정도로 멋진 시스템을 구축하고 싶어합니다.

그러나 개발자는 이전에는 필요하지 않았기 때문에 서버 구매 경험과 필요한 서버 크기를 결정하는 기술이 없습니다. 그리고 그들은 일반적으로 확장성과 성능의 차이를 잘 이해하지 못합니다.

인벤토리 결과:

• 우리는 같은 데이터 센터를 떠났습니다.
• 로그 서비스 3개와의 계약을 종료했습니다. 그 중 5개가 있었기 때문에 어떤 것을 가지고 놀기 시작한 모든 개발자는 새로운 것을 가져갔습니다.
• 7개의 AWS 시스템이 종료되었습니다. 다시 말하지만, 아무도 죽은 프로젝트를 중단하지 않았고 모두 계속 작업했습니다.
• 소프트웨어 비용을 6배 절감했습니다.

일흔다섯째날

시간이 흘러 두 달 반 만에 이사회를 만나야 했습니다. 우리 이사회는 다른 이사회보다 더 좋거나 나쁘지 않으며 모든 이사회와 마찬가지로 모든 것을 알고 싶어합니다. 사람들은 돈을 투자하고 우리가 하는 일이 설정된 KPI에 얼마나 부합하는지 알고 싶어합니다.

이사회는 매달 사용자 수, 성장, 사용하는 서비스 및 방법, 성능 및 생산성, 평균 페이지 로딩 속도 등 많은 정보를 받습니다.

유일한 문제는 평균이 순수한 악이라고 믿는다는 것입니다. 하지만 이를 이사회에 설명하는 것은 매우 어렵다. 예를 들어 초당 로딩 시간의 분포가 아닌 집계된 숫자로 작업하는 데 익숙합니다.

이와 관련하여 몇 가지 흥미로운 점이 있었습니다. 예를 들어 콘텐츠 유형에 따라 별도의 웹 서버 간에 트래픽을 분할해야 한다고 말씀드렸습니다.

즉, ColdFusion은 Jetty와 nginx를 거쳐 페이지를 시작합니다. 그리고 이미지, JS 및 CSS는 자체 구성으로 별도의 nginx를 거칩니다. 이것은 제가 말하는 상당히 표준적인 관행입니다. 내가 쓴 몇 년 전. 결과적으로 사진 로딩 속도가 훨씬 빨라졌고... 평균 로딩 속도도 200ms 증가했습니다.

이는 Jetty와 함께 제공되는 데이터를 기반으로 그래프가 작성되었기 때문에 발생했습니다. 즉, 빠른 콘텐츠는 계산에 포함되지 않습니다. 즉, 평균값이 급등했습니다. 이것은 우리에게 분명했고 우리는 웃었습니다. 그러나 우리가 어떤 일을 했고 상황이 12%나 더 악화된 이유를 이사회에 어떻게 설명할 수 있습니까?

여든다섯 번째 날

세 번째 달이 끝나갈 무렵, 나는 전혀 예상하지 못했던 한 가지가 있다는 것을 깨달았습니다. 바로 시간이었습니다. 제가 이야기한 모든 것에는 시간이 걸립니다.

이것은 나의 실제 주간 달력입니다. 별로 바쁘지 않은 일주일의 업무일 뿐입니다. 모든 것에 시간이 충분하지 않습니다. 그러므로 다시 한번 문제에 대처하는 데 도움을 줄 사람들을 모집해야 합니다.

결론

그게 다가 아닙니다. 이 이야기에서는 우리가 제품을 어떻게 작업하고 일반적인 흐름에 맞추려고 노력했는지, 기술 지원을 어떻게 통합했는지, 다른 기술 문제를 어떻게 해결했는지조차 다루지 않았습니다. 예를 들어, 데이터베이스의 가장 큰 테이블에서는 우리가 사용하지 않는다는 사실을 우연히 알게 되었습니다. SEQUENCE. 자체 작성 기능이 있습니다 nextID이며 트랜잭션에는 사용되지 않습니다.

우리가 오랫동안 이야기할 수 있는 비슷한 것들이 백만 개 더 있었습니다. 하지만 여전히 말해야 할 가장 중요한 것은 문화입니다.

다른 모든 문제를 일으키는 것은 문화 또는 문화의 부족입니다. 우리는 사람들이 다음과 같은 문화를 구축하려고 노력하고 있습니다.

• 실패를 두려워하지 않는다.
• 실수로부터 배우십시오.
• 다른 팀과 협력합니다.
• 주도권을 쥐다;
• 책임감을 가지다;
• 결과를 목표로 환영합니다.
• 성공을 축하합니다.

이것으로 다른 모든 것이 올 것입니다.

레온 파이어 트위터에서, 페이스북 과 매질.

유산에 관한 두 가지 전략이 있습니다. 어떤 대가를 치르더라도 유산에 대한 작업을 피하거나 관련 어려움을 용감하게 극복하는 것입니다. 우리는 c DevOpsConf 우리는 프로세스와 접근 방식을 바꾸는 두 번째 길을 택하고 있습니다. 우리와 함께하세요 유튜브, 메일링 리스트 и 전보, 우리는 함께 DevOps 문화를 구현할 것입니다.

출처 : habr.com