개발자는 화성에서, 관리자는 금성에서 왔습니다.

우연의 일치는 무작위이며 실제로는 다른 행성에서 발생했습니다 ...

백엔드 개발자가 관리자와 팀을 이루어 일하는 방식에 대한 세 가지 성공 및 실패 사례를 공유하고 싶습니다.

먼저 역사.
웹스튜디오, 직원 수는 한 손에 꼽힐 정도입니다. 오늘은 레이아웃 디자이너이고, 내일은 백엔더이고, 모레는 관리자입니다. 한편으로는 엄청난 경험을 얻을 수 있습니다. 반면에 모든 분야에서 역량이 부족합니다. 나는 아직도 근무 첫날을 기억하고 있고, 아직 초록색이고, 상사가 "퍼티를 열어라"라고 말하지만 그것이 무엇인지 모르겠습니다. 관리자와의 통신은 제외됩니다. 당신은 관리자입니다. 이 상황의 장점과 단점을 생각해 봅시다.

+ 모든 권력이 당신의 손에 있습니다.
+ 서버에 접근하기 위해 누구에게도 구걸할 필요가 없습니다.
+ 모든 방향에서 빠른 반응 시간.
+ 기술이 잘 향상됩니다.
+ 제품 아키텍처를 완전히 이해하십시오.

— 높은 책임감.
— 생산이 중단될 위험이 있습니다.
— 모든 분야에서 좋은 전문가가 되기는 어렵다.

관심없으니 다음으로 넘어가자

두 번째 이야기.
대기업, 대규모 프로젝트. 5~7명의 직원과 여러 개발 그룹으로 구성된 관리 부서가 있습니다. 그런 회사에 일하러 오면 모든 관리자는 제품 작업을 하러 온 것이 아니라 무언가를 깨뜨리기 위해 왔다고 생각합니다. 서명된 NDA나 인터뷰에서의 선택 모두 달리 명시되지 않습니다. 아니, 이 남자는 우리의 키스 프로덕션을 망치려고 더러운 작은 손을 가지고 여기 왔습니다. 따라서 그러한 사람에게는 최소한의 의사 소통이 필요하며 최소한 이에 대한 응답으로 스티커를 던질 수 있습니다. 프로젝트 아키텍처에 관한 질문에는 대답하지 마세요. 팀 리더가 요청할 때까지 액세스 권한을 부여하지 않는 것이 좋습니다. 그리고 그가 요청할 때, 그는 그들이 요청한 것보다 훨씬 적은 특권으로 그것을 돌려줄 것입니다. 이러한 관리자와의 거의 모든 커뮤니케이션은 개발 부서와 관리 부서 사이의 블랙홀에 의해 흡수됩니다. 문제를 즉시 해결하는 것은 불가능합니다. 하지만 직접 올 수는 없습니다. 관리자가 연중무휴로 너무 바빠서요. (당신은 항상 무엇을 하고 있나요?) 일부 성능 특성:

• 프로덕션 환경의 평균 배포 시간은 4~5시간입니다.
• 프로덕션에서 최대 배포 시간 9시간
• 개발자에게 프로덕션 중인 애플리케이션은 프로덕션 서버 자체와 마찬가지로 블랙박스입니다. 총 몇 개인가요?
• 낮은 릴리스 품질, 빈번한 오류
• 개발자는 릴리스 프로세스에 참여하지 않습니다.

글쎄, 내가 기대했던 것은 물론 새로운 사람들이 생산에 허용되지 않습니다. 글쎄요, 인내심을 얻은 후 우리는 다른 사람들의 신뢰를 얻기 시작합니다. 그러나 어떤 이유로 관리자에게는 일이 그렇게 간단하지 않습니다.

Act 1. 관리자는 보이지 않습니다.
출시일, 개발자와 관리자는 소통하지 않습니다. 관리자는 질문이 없습니다. 하지만 나중에 그 이유를 이해하게 됩니다. 관리자는 원칙을 지키는 사람이고, 메신저도 없고, 누구에게도 전화번호를 알려주지 않으며, 소셜 네트워크에 프로필도 없습니다. 그 사람 사진 어디에도 없는데, 넌 어떻게 생겼어? 우리는 이 보이저 15호와 통신을 시도하면서 당황한 채 약 1분 동안 책임 관리자와 함께 앉아 있었는데, 그가 완료한 회사 이메일에 메시지가 나타납니다. 우리는 우편으로 연락할 건가요? 왜 안 돼? 편리하지 않나요? 알았어, 진정하자. 프로세스가 이미 진행 중이므로 되돌릴 수 없습니다. 메시지를 다시 읽어보세요. "나는 끝났다". 무엇을 마쳤나요? 어디? 어디서 당신을 찾아야 합니까? 여기에서 출시에 4시간이 걸리는 것이 일반적인 이유를 이해하실 수 있습니다. 개발 충격을 받았지만 출시를 마쳤습니다. 더 이상 풀어주고 싶은 마음이 없습니다.

Act 2. 그 버전이 아닙니다.
다음 릴리스. 경험을 쌓은 후 관리자용 서버에 필요한 소프트웨어 및 라이브러리 목록을 작성하여 일부 버전을 표시하기 시작합니다. 언제나 그렇듯이 관리자가 그곳에서 작업을 완료했다는 약한 무선 신호를 수신합니다. 회귀 테스트가 시작되며 테스트 자체에는 약 XNUMX시간이 소요됩니다. 모든 것이 작동하는 것 같지만 치명적인 버그가 하나 있습니다. 중요한 기능이 작동하지 않습니다. 다음 몇 시간 동안은 탬버린과 함께 춤을 추고, 커피 찌꺼기에서 점을 치고, 각 코드에 대한 자세한 검토를 했습니다. 관리자는 모든 작업을 완료했다고 말합니다. 비뚤어진 개발자가 작성한 애플리케이션은 작동하지 않지만 서버는 작동합니다. 그에게 질문이 있나요? 한 시간이 지나면 관리자에게 프로덕션 서버에 있는 라이브러리 버전을 채팅과 빙고로 보내도록 요청합니다. 이는 우리에게 필요한 것이 아닙니다. 관리자에게 필요한 버전을 설치하도록 요청했지만 이에 대한 응답으로 OS 패키지 관리자에 이 버전이 없기 때문에 이를 수행할 수 없다는 답변을 받았습니다. 여기에서 관리자는 다른 관리자가 필요한 버전을 손으로 간단히 조립하여 이미 이 문제를 해결했다는 것을 기억하고 있습니다. 하지만 아닙니다. 우리는 이것을하지 않을 것입니다. 규정에서는 금지하고 있습니다. 칼, 우리 여기 몇 시간 동안 앉아 있었는데, 시간 제한이 어떻게 되나요?! 우리는 또 다른 충격을 받고 어떻게든 출시를 마무리합니다.

3막, 단편
긴급 티켓, 프로덕션 사용자 중 한 명에게는 주요 기능이 작동하지 않습니다. 우리는 찌르고 확인하는 데 몇 시간을 보냅니다. 개발 환경에서는 모든 것이 작동합니다. php-fpm 로그를 살펴보는 것이 좋은 아이디어라는 점은 분명하게 이해되어 있습니다. 당시 프로젝트에는 ELK나 Prometheus와 같은 로그 시스템이 없었습니다. 서버의 php-fpm 로그에 대한 액세스 권한을 부여하도록 관리 부서에 티켓을 엽니다. 여기에서 우리가 액세스를 요청하는 데는 이유가 있다는 점을 이해해야 합니다. 블랙홀과 관리자가 연중무휴로 바쁜 것을 기억하지 않습니까? 로그 자체를 보라고 요청하면 이는 "이생에서는 없음" 우선 순위가 있는 작업입니다. 티켓이 생성되었고 관리 부서장으로부터 "프로덕션 로그에 액세스할 필요가 없으며 버그 없이 작성하면 안 됩니다."라는 즉각적인 응답을 받았습니다. 커튼.

액트 4 이상
우리는 여전히 다양한 버전의 라이브러리, 구성되지 않은 소프트웨어, 준비되지 않은 서버 로드 및 기타 문제로 인해 프로덕션에서 수십 가지 문제를 수집하고 있습니다. 물론 코드 버그도 있습니다. 모든 죄에 대해 관리자를 비난하지는 않을 것입니다. 해당 프로젝트의 일반적인 작업을 한 가지 더 언급하겠습니다. 감독자를 통해 시작된 백그라운드 작업자가 꽤 많았고 일부 스크립트를 cron에 추가해야 했습니다. 때로는 동일한 직원이 작업을 중단하기도 했습니다. 대기열 서버의 부하가 빛의 속도로 증가했고, 안타까운 사용자들은 회전하는 로더를 바라봤습니다. 이러한 작업자를 신속하게 수정하려면 단순히 다시 시작하는 것만으로도 충분했지만 이 작업도 관리자만 수행할 수 있었습니다. 이러한 기본적인 작업을 수행하는 동안 하루 종일이 걸릴 수 있습니다. 물론 비뚤어진 프로그래머는 작업자가 충돌하지 않도록 작성해야 한다는 점은 주목할 가치가 있지만, 작업자가 추락하면 생산에 대한 액세스 부족으로 인해 때때로 불가능한 이유를 이해하는 것이 좋을 것입니다. 물론 결과적으로 개발자의 로그가 부족합니다.

변형.
이 모든 것을 꽤 오랫동안 견뎌낸 후, 우리는 팀과 함께 우리에게 더 성공적인 방향으로 나아가기 시작했습니다. 요약하자면, 우리는 어떤 문제에 직면했습니까?

• 개발자와 관리 부서 간의 양질의 의사 소통 부족
• 관리자는 애플리케이션이 어떻게 구성되어 있는지, 어떤 종속성이 있는지, 어떻게 작동하는지 전혀 이해하지 못하는 것으로 나타났습니다.
• 개발자는 프로덕션 환경이 어떻게 작동하는지 이해하지 못하므로 문제에 효과적으로 대응할 수 없습니다.
• 배포 프로세스가 너무 오래 걸립니다.
• 불안정한 릴리스.

우리는 무엇을 했습니까?
각 릴리스에 대해 다음 릴리스가 작동하기 위해 서버에서 수행해야 하는 작업 목록이 포함된 릴리스 노트 목록이 생성되었습니다. 목록에는 여러 섹션, 관리자, 릴리스 책임자 및 개발자가 수행해야 하는 작업이 포함되어 있습니다. 개발자는 모든 프로덕션 서버에 대해 루트가 아닌 액세스 권한을 얻었으며 이로 인해 전반적인 개발 속도는 물론 특히 문제 해결 속도가 빨라졌습니다. 개발자는 또한 생산이 어떻게 진행되는지, 어떤 서비스로 나뉘는지, 복제본의 위치와 비용이 얼마나 되는지 이해하고 있습니다. 일부 전투 부하가 더 명확해졌으며 이는 의심할 여지없이 코드 품질에 영향을 미칩니다. 출시 과정 중 커뮤니케이션은 인스턴트 메신저 중 하나의 채팅을 통해 이루어졌습니다. 첫째, 우리는 모든 행동에 대한 로그를 갖고 있었고, 둘째, 더 가까운 환경에서 커뮤니케이션이 이루어졌습니다. 행동 이력이 있으면 신입 직원이 문제를 더 빨리 해결할 수 있었습니다. 역설적이지만 이는 종종 관리자 자신에게 도움이 되었습니다. 확실히 말씀드릴 수는 없지만 관리자들이 프로젝트의 작동 방식과 작성 방식을 더 많이 이해하기 시작한 것 같습니다. 때때로 우리는 서로 세부 사항을 공유하기도 했습니다. 평균 출시 시간이 30시간으로 단축되었습니다. 때로는 40~XNUMX분 만에 끝날 때도 있었습니다. 버그 수가 XNUMX배는 아니더라도 크게 감소했습니다. 물론 자동 테스트와 같은 다른 요인도 릴리스 시간 단축에 영향을 미쳤습니다. 각 릴리스 후에 우리는 회고전을 시작했습니다. 팀 전체가 새로운 점, 변경된 점, 제거된 점에 대한 아이디어를 가질 수 있도록 합니다. 아쉽게도 관리자들이 항상 찾아오지는 않았고, 글쎄요, 관리자들은 바쁘네요... 개발자로서의 직업 만족도는 의심할 여지 없이 높아졌습니다. 귀하의 역량 분야에 있는 거의 모든 문제를 신속하게 해결할 수 있으면 최고의 기분을 느낄 수 있습니다. 물론 완전하지는 않지만 어느 정도 데브옵스 문화를 도입했다는 것은 나중에 이해하겠지만, 변화의 시작조차 인상적이었다.

세 번째 이야기
시작. 한 명의 관리자, 소규모 개발 부서. 도착하자마자 나는 완전한 XNUMX이 되었습니다. 왜냐면... 메일 외에는 어디에도 접근할 수 없습니다. 우리는 관리자에게 편지를 쓰고 액세스를 요청합니다. 또한 신입사원에 대해 알고 로그인/비밀번호 발급이 필요하다는 정보도 있습니다. 저장소와 VPN에서 액세스를 제공합니다. Wiki, teamcity, rundesk에 대한 액세스 권한을 부여하는 이유는 무엇입니까? 전체 백엔드 부분을 작성하도록 부름받은 사람에게는 쓸모없는 것입니다. 시간이 지남에 따라 일부 도구에 액세스할 수 있게 됩니다. 물론 도착은 불신에 부딪혔습니다. 채팅과 유도 질문을 통해 프로젝트의 인프라가 어떻게 작동하는지 천천히 느끼려고 노력하고 있습니다. 기본적으로 나는 아무것도 인식하지 못합니다. 제작은 기존과 동일한 블랙박스입니다. 하지만 그보다 테스트에 사용된 스테이지 서버조차 블랙박스다. Git에서 브랜치를 배포하는 것 외에는 아무것도 할 수 없습니다. 또한 .env 파일처럼 애플리케이션을 구성할 수도 없습니다. 그러한 작업에 대한 액세스 권한은 부여되지 않습니다. 테스트 서버의 애플리케이션 구성에서 한 줄을 변경해달라고 간청해야 합니다. (관리자가 프로젝트에서 자신이 중요하다고 느끼는 것이 중요하다는 이론이 있습니다. 구성에서 줄을 변경하라는 요청을 받지 않으면 단순히 필요하지 않을 것입니다.) 뭐, 늘 그렇듯 편리하지 않나요? 관리자와 직접 대화한 후 우리는 개발자가 나쁜 코드를 작성하기 위해 태어났고 본질적으로 무능한 개인이므로 프로덕션에서 멀리하는 것이 더 낫다는 것을 알게 되었습니다. 그러나 만일의 경우를 대비해 테스트 서버에서도 마찬가지입니다. 갈등이 빠르게 확대되고 있습니다. 관리자와 통신이 없습니다. 그가 혼자라는 사실로 인해 상황은 더욱 악화됩니다. 다음은 대표적인 그림이다. 풀어 주다. 특정 기능이 작동하지 않습니다. 무슨 일이 일어나고 있는지 파악하는 데 오랜 시간이 걸리고 개발자의 다양한 아이디어가 채팅에 던져지지만 이러한 상황의 관리자는 일반적으로 개발자의 책임이 있다고 가정합니다. 그런 다음 그는 채팅에 글을 쓰고 잠깐만 요. 내가 그를 수정했습니다. 문제가 무엇인지에 대한 정보와 함께 이야기를 남겨 달라는 요청을 받으면 우리는 해로운 변명을 듣습니다. 예를 들어, 코가 속하지 않는 곳에 코를 붙이지 마십시오. 개발자는 코드를 작성해야 합니다. 프로젝트에서 많은 신체 움직임이 한 사람을 통해 이루어지고 오직 그 사람만이 모든 사람이 필요로 하는 작업을 수행할 수 있는 상황은 매우 슬픈 일입니다. 그런 사람은 끔찍한 병목 현상입니다. Devops 아이디어가 출시 시간을 단축하려고 노력한다면 그러한 사람들은 Devops 아이디어의 최악의 적입니다. 아쉽게도 여기서 막이 닫힙니다.

PS 사람들과의 채팅에서 개발자와 관리자에 대한 이야기를 조금 나눈 후, 나의 고통을 공유하는 사람들을 만났습니다. 하지만 이런 일을 겪어본 적이 없다고 말하는 사람들도 있었습니다. 한 데브옵스 컨퍼런스에서 나는 Anton Isanin(Alfa Bank)에게 관리자 형태로 병목 현상 문제를 어떻게 처리하는지 물었고 그는 "우리는 이를 버튼으로 대체했습니다"라고 말했습니다. 그런데 팟캐스트 그의 참여로. 나는 적보다 좋은 관리자가 더 많다고 믿고 싶습니다. 그리고 네, 시작 부분의 그림은 실제 서신입니다.

출처: www.habr.com