프로그래머, 데브옵스, 슈뢰딩거의 고양이

네트워크 엔지니어의 현실(국수와..소금?)

최근 엔지니어들과 다양한 사건에 대해 논의하던 중 흥미로운 패턴을 발견했습니다.

이러한 논의에서는 '근본 원인'에 대한 질문이 항상 등장합니다. 충실한 독자들은 아마도 내가 그랬다는 것을 알고 있을 것입니다. 여러 생각 에 이 약. 많은 조직에서 사고 분석은 전적으로 이 개념을 기반으로 합니다. 그들은 원인과 결과 관계를 식별하기 위해 다음과 같은 다양한 기술을 사용합니다. "XNUMX가지 이유". 이러한 방법은 소위 "사건의 선형성"을 확실한 교리로 가정합니다.

이 아이디어에 도전하고 선형성이 복잡한 시스템에서 기만적이라는 점을 지적하면 흥미로운 토론이 탄생합니다. 논쟁자들은 "근본 원인"에 대한 지식만이 우리가 무슨 일이 일어나고 있는지 이해할 수 있다고 열렬히 주장합니다.

나는 흥미로운 패턴을 발견했습니다. 개발자와 DevOps는 이 아이디어에 다르게 반응합니다. 내 경험에 따르면 개발자들은 근본 원인이 중요하며 인과 관계는 항상 이벤트에서 확립될 수 있다고 주장할 가능성이 높습니다. 반면에 DevOps는 복잡한 세계가 항상 선형성을 따르지는 않는다는 데 더 자주 동의합니다.

항상 궁금했는데 왜 그럴까요? 무엇 ~을 만든다 프로그래머들이 “근본 원인은 신화다”라는 생각을 그렇게 비판할 수 있겠습니까? 외부 물질을 인식하는 면역 체계와 같습니다. 왜 그들은 이런 식으로 반응하는 반면, 데브옵스는 오히려 기울어져 있다 이 아이디어를 고려해 볼까?

완전히 확신할 수는 없지만 이에 대해 몇 가지 생각이 있습니다. 이는 이러한 전문가들이 일상 업무를 수행하는 다양한 상황과 관련이 있습니다.

개발자는 종종 결정론적 도구를 사용하여 작업합니다. 물론 컴파일러, 링커, 운영 체제 등은 모두 복잡한 시스템이지만 우리는 이들이 결정론적인 결과를 제공한다는 사실에 익숙하며 이를 결정론적이라고 상상합니다. 동일한 입력 데이터를 제공하면 일반적으로 다음을 기대합니다. 이 시스템의 동일한 출력. 그리고 출력에 문제(“버그”)가 있는 경우 개발자는 입력 데이터(사용자 또는 개발 프로세스 중 도구 세트에서 얻은 데이터)를 분석하여 문제를 해결합니다. 그들은 "오류"를 찾은 다음 입력 데이터를 변경합니다. 이것은 "버그"를 수정합니다.

소프트웨어 개발의 기본 가정: 동일한 입력 데이터는 안정적이고 결정론적으로 동일한 출력을 생성합니다.

실제로 비결정적 결과 자체는 버그로 간주됩니다. 예상치 못한 또는 잘못된 출력이 재현되지 않으면 개발자는 스택의 다른 부분(운영 체제, 네트워크 등)으로 조사를 확장하는 경향이 있습니다. 어느 정도 결정론적으로 동일한 입력 데이터로 동일한 결과를 생성합니다. 그렇지 않다면, 이는 여전히 버그로 간주됩니다. 지금은 운영 체제나 네트워크 버그일 뿐입니다.

어쨌든 결정론은 프로그래머가 수행하는 대부분의 작업에 대해 기본적이고 거의 당연하게 여겨지는 가정입니다.

그러나 하드웨어를 준비하거나 클라우드 API를 알아내느라 하루를 보낸 데브옵스 전문가에게 완전히 결정적인 세계(모든 입력을 매핑하는 것이 가능한 한!)에 대한 아이디어는 기껏해야 덧없는 개념입니다. 옆으로 치워두어도 BOHF의 흑점에 대한 농담, 숙련된 엔지니어들은 이 세상에서 가장 이상한 것을 보았습니다. 그들은 그것을 알고 있다 사람의 비명 소리도 서버 속도를 늦출 수 있습니다, 환경에 있는 수백만 가지 다른 요소는 말할 것도 없습니다.

따라서 숙련된 엔지니어는 모든 사고에 단일 근본 원인이 있고 "XNUMX가지 이유"와 같은 기술이 해당 근본 원인을 올바르게(반복적으로!) 이끌어 낼 수 있다는 사실을 의심하기가 더 쉽습니다. 사실, 이것은 퍼즐 조각이 실제로 그렇게 깔끔하게 맞지 않는 그들 자신의 경험과 모순됩니다. 그러므로 그들은 이 생각을 더 쉽게 받아들인다.

물론 개발자들이 순진하거나 멍청하거나 선형성이 어떻게 기만적인지 이해하지 못한다고 말하는 것은 아닙니다. 숙련된 프로그래머라면 아마도 그 당시에 비결정론을 많이 보아왔을 것입니다.

그러나 제가 보기에 이러한 논쟁에서 개발자들의 공통적인 반응은 종종 결정론의 개념이 다음과 같다는 사실과 관련이 있는 것 같습니다. 전반적으로 잘 서비스를 제공합니다 일상 업무에서. 엔지니어들이 인프라에서 슈뢰딩거의 고양이를 잡아야 하는 것만큼 자주 비결정론을 접하지는 않습니다.

이는 관찰된 개발자 반응을 완전히 설명할 수는 없지만, 우리의 반응은 여러 요인의 복잡한 혼합이라는 점을 강력히 상기시켜 줍니다.

단일 사고를 처리하든, 소프트웨어 제공 파이프라인에서 협업하든, 더 넓은 세상을 이해하려고 노력하든 관계없이 이러한 복잡성을 기억하는 것이 중요합니다.

출처 : habr.com