Yun Shao Haiyang의 또 다른 장면: 25년 경력의 Linux 베테랑이 DevOps의 8가지 명예와 8가지 불명예에 대해 이야기합니다.

인터뷰와 원고 요청을 통해 운영 및 유지 관리 분야의 베테랑을 초대하여 심오한 통찰력을 제공하고 서로 충돌하여 발전된 공감대를 형성하고 업계가 더 나은 발전을 이룰 수 있도록 장려합니다.

이번 호에는 Linux 25년 베테랑인 Youpaiyun Technology의 Shao Haiyang을 초대합니다. Shao 씨는 기술에 집착하여 한 단계씩 발전하고 있습니다. 오늘 인터뷰가 당신에게 영감을 줄 수 있기를 바랍니다.

현실적이고 수준 높은 "​​백 운영 및 유지 보수 포럼​​"의 4번째 호입니다. 시작하겠습니다!

안녕하세요 Mr. Shao, 먼저 자기 소개를 하고, 모든 사람이 당신을 더 잘 알 수 있도록 이력서와 현재 상황에 대해 이야기해 주세요. 당신의 배경을 이해하는 것도 독자들이 다음 인터뷰의 내용을 이해하는 데 도움이 됩니다.

저는 Youpaiyun Technology의 Shao Haiyang입니다. 저는 1998년부터 거의 25년 동안 Linux를 사용해 왔습니다. 저는 선배(베테랑) Linux 시스템 운영 및 유지 관리/설계자, DevOps 8영예 및 8패 옹호자, 아마추어 작가입니다. . (유죄) 시스템 최적화 및 네트워크 서비스 관리, Linux 시스템 사용자 정의, CDN 가속 및 보안 방어에 능숙하며, 고성능 인터넷 네트워크 및 아키텍처 설계, 가상화된 KVM 및 OpenStack 클라우드 플랫폼, K8S 컨테이너 클라우드 및 Ceph 분산 스토리지에 능숙합니다. 및 기타 신기술 기술은 소통과 공유를 좋아하고 커뮤니티에서 활발히 활동하며 오픈 소스 활동의 조직 및 보급에 적극적으로 참여해 왔습니다.

운영 및 유지 관리 분야에서는 각 회사에서 자체적인 운영 및 유지 관리 지침이나 운영 사양을 수립하게 됩니다. 귀사의 경험을 공유하고 참고할 수 있나요?

Youpaiyun은 클라우드 스토리지, 클라우드 배포, 클라우드 처리 서비스를 제공하는 회사이기도 하며 프로그래밍 가능한 CDN 서비스를 제공하는 중국 최초의 전문 클라우드 서비스 제공업체이기도 합니다. 운영 및 유지 관리에도 다음과 같은 몇 가지 규칙이나 원칙이 있습니다.

먼저 안정성을 확보한 다음 최적화하세요.

과도한 설계 또는 조기 최적화로 인해 다운타임이 늘어날 가능성이 높으므로 먼저 확장성과 고성능을 개선하는 데 집중해야 합니다. 시스템의 가용성. 이 프로젝트는 "먼저 완성하고 그 다음 완벽하고 그 다음 완벽하다"라는 원칙을 고수하며 "먼저 사용 가능하고 그 다음 사용하기 쉽고 그 다음 사용하기 좋다"라는 구현 전략을 채택합니다.

신뢰할 수 있는 테스트 기반 및 시간 검증 제공

신기술을 아키텍처에 도입하기 전에 신기술의 안정성과 충분한 장기 테스트, 운영 및 개발 과정에서 개발된 툴 체인의 무결성을 보장해야 합니다. 유지관리공학 . 온라인 재작업이나 변경으로 인해 허를 찔린 것이 이미 실패의 원인이 되었을 수도 있습니다.

제어 가능한 자동화 방법을 사용하여 효율성 향상

자동 배포, 자동 오케스트레이션, 자동 검사, 자동 업그레이드와 같은 자동화 방법이 클라우드 운영 및 유지 관리에 점점 더 많이 사용되고 있습니다. 이는 클라우드 컴퓨팅 시대에 적응하는 추세이지만, 기능이 커질수록 책임도 커집니다. 자동화로 인한 눈사태와 엄청난 양의 무리 효과에 주의하고 그레이스케일/청록색 배포 및 다양한 테스트를 잘 수행하세요.

단순하게 유지하고 모든 것을 모니터링하세요

단순하게 유지하고 너무 복잡하게 만들지 마세요. 일반적인 비정상 문제 경보 외에도 비즈니스 지표, 시장 지표, 판매 데이터, 비용 등을 모두 추세 분석 정보로 사용할 수 있습니다. 정기적인 폴링을 통해 각 추세 데이터의 최고점과 최저점을 확인하면 통찰력을 얻는 데 도움이 될 수 있습니다.

예산 중심의 운영 및 유지 보수

일반적으로 운영 및 유지 관리팀이 가장 큰 지출을 담당합니다. 왜냐하면 예산이 부족하고 회사 사업의 규모 증가를 고려하여 돈 없이는 운영 및 유지 관리가 어렵기 때문입니다. , 회사의 사업이 정체되거나 더 이상 존재하지 않는 한 폭발적인 성장이 이루어지고 있습니다. 그러한 과제에 직면한 운영 및 유지 관리는 비용을 절감하고 이익을 얻고, 수익을 늘리고 지출을 줄이고, 에너지 효율성을 향상시키기 위해 새로운 기술을 사용하는 방법을 배워야 합니다.

시나리오 중심의 지능형 운영 및 유지보수

고동시 처리부터 비디오 트랜스코딩, 고성능 병렬 컴퓨팅부터 대규모 네트워크 요청까지 다양한 부하 시나리오. 이러한 다양한 로드 시나리오에는 네트워크 대역폭, 다양한 처리 및 IO에 대한 요구 사항이 다릅니다. 지능적인 운영 및 유지 관리를 위해서는 비즈니스에 대한 심층적인 이해와 다양한 비즈니스 시나리오의 요구 사항을 충족하기 위한 리소스 및 아키텍처의 합리적인 할당이 필요합니다.

지속적 통합 및 릴리스 시스템

지속적 릴리스에는 그레이스케일 릴리스, 테스트 릴리스, 롤링 릴리스, 롤백 릴리스 및 기타 시나리오가 포함되며 각 시나리오를 제어할 수 있어야 합니다.

누구나 교체될 수 있도록 보장하세요

철저한 캠프에서는 사람들이 이리저리 이동하는 것이 정상입니다. 공유 문서 관리와 직원 간 지식 전달 및 공유를 잘 수행하세요. 누구든지 교체할 수 있으며, 그것이 회사의 한계가 되어서도 안 됩니다.

성장은 본인의 사업이지만 올바른 분야, 올바른 프로젝트 기회, 올바른 팀, 올바른 메커니즘이 있으면 엔지니어가 더 빠르게 성장하고 팀이 더 체계적으로 논의할 수 있습니까? 운영 및 유지 보수 학생들의 성장을 촉진합니까?

회사는 직원들이 스스로 기술을 향상하고 성장을 촉진할 수 있도록 항상 적극적으로 장려해 왔습니다.

• 월간 오픈 데이: 회사 기술위원회에서 정기적인 강의를 열어 최첨단 연구 성과를 공유하며 주제가 필요합니다. 그리고 적용 시나리오가 있다면 예시를 갖는 것이 가장 좋습니다.
• 주간 공유 모임: 모든 개발자는 정기적으로 새로운 기술을 공유하고, 직면한 문제 또는 생각하는 모든 것에 대해 이야기하도록 권장됩니다. 공유된 콘텐츠는 문서와 비디오 아카이브로 구성되며 보너스와 보상이 제공됩니다. 점수에 따라 인센티브를 제공합니다.
• 회사 포상금 프로젝트: 회사 또는 직원이 직접 프로젝트를 시작할 수 있으며, 기술 위원회의 검토를 통과한 후 팀을 구성하여 출력 문서, 데이터 비교 및 ​​기술 공유를 통해 완료할 수 있습니다. 해당 프로젝트 보너스를 받게 됩니다. 특허 신청에 대한 해당 특허 보너스가 있습니다.
• 개인 영향력 함양: 개인 영향력 향상을 위해 기사나 연설을 게재하여 직원들이 나가서 엔지니어링 경험을 공유하고 업무 경험을 정리하도록 장려하고, 청중 피드백을 바탕으로 원고료 및 강의료에 대한 인센티브를 제공합니다.
• 신문, 잡지, 기타 종이책을 구독하여 최신 뉴스를 알아보세요. 학과별로 도서구입에 대한 일정 금액을 배정하고 있습니다.

클라우드 운영 및 유지 관리 팀 내 교육에는 다음이 포함됩니다.

• "천장을 지지판으로 전환": 새로운 직원을 교육하는 관리 역할을 맡기고 회사와 업무의 병목 현상이 되지 않도록 하십시오. 새로운 일을 시도하고 실패에 대처하고, 자신의 기술과 실제 경험을 늘리고, 서로 돕고 영감을 주기 위해 계속해서 놀라움을 선사할 것입니다.
• "자동화 도구" 생성: 자신의 경험을 사용하여 비즈니스를 프로그램 모델로 추상화하고, 자동화된 스크립트 작성을 생성 또는 교육하고, 팀의 작업 효율성을 향상시키고, 직원이 에너지와 시간을 절약하여 다른 새로운 지식을 배울 수 있도록 합니다.
• "고정밀" "전문" 프로젝트 담당: 최신 지식에 대한 연구 및 타당성 분석을 사전에 준비하고 이를 공개 교육용 문서로 정리한 후 심층적인 연구 및 구현을 위해 팀에 넘겨줍니다. 이를 생산성으로 전환하고, 일선 경험을 축적한 후 피드백을 제공하여 문서를 개선하는 선순환입니다.
• 긍정적 "지식 공유" 촉진: 문서 공유 및 정기적인 작업을 통해 다양한 사례와 "구덩이"가 컴파일됩니다. 강의를 공유하면 직원들이 고품질의 가독성 높은 문서를 작성하고 교육에 개방되어 매력과 자신감을 높일 수 있습니다.
• "오픈 소스 교환 참여" 장려: 회사는 직원들이 밖으로 나가서 기술 교류 회의. 비공개로 작업하는 것은 시간이 많이 걸리고 노동 집약적이며 지침을 제공하는 것은 전문가만큼 좋지 않습니다. 도서 구매, 팀빌딩 활동, 다과 문화를 위한 자금도 제공됩니다.

운영 및 유지 관리 엔지니어의 일반적인 경력 중 하나는 관리자가 되는 것이지만 관리자와 고위 운영 및 유지 관리에 대한 문제는 다음과 같습니다. 엔지니어들이 해결해야 할 문제는 완전히 다릅니다. 이제 막 관리 직위에 오른 수석 운영 및 유지보수 담당자로서 귀하의 경험을 공유해 주실 수 있습니까?

이제 막 경영직에 들어온 분들에게는 남은 기술부채와 재고를 정리하고 적시에 인재 역량을 키워 나중에 발전할 여지가 더 커지도록 하라고 제안합니다. 자세한 내용은 제가 공유한 "​​DevOps의 8가지 명예​와 8가지​​"를 참조하세요.

• 1. 설정 가능한 걸 자랑하고 하드코딩을 부끄러워하라
• 2. 상호 제공을 자랑하고 단일 포인트를 부끄러워하라
• 3. 언제든지 다시 시작하는 것을 자랑하고 마이그레이션할 수 없는 것을 부끄러워하라
• 4. 전체 배송을 자랑하고, 부분 배송을 부끄러워하세요
• 5. 무국적을 자랑하고, 상태를 부끄러워하세요
• 6. 표준화를 자랑하고, 전문화를 부끄러워하세요
• 7 . 자동화 도구를 자랑스러워하세요, 수동 작업과 인간 육체를 부끄러워하세요
• 8. 무인을 자랑스러워하고 수동 개입을 부끄러워하세요

스킬 트리의 재능 목록은 주로 인적 자원과 협력하여 재능을 나누는 것입니다. 9개의 궁전으로 (개발 또는 운영 및 유지 관리의 경우 왼쪽의 성과를 잠재력으로 대체합니다. (성과는 판매를 위한 성과입니다.) 테스트되는 것은 직원의 모든 측면을 분석하고 이를 효과적으로 활용할 수 있는 관리자의 능력입니다. .

직원들에게 동기를 부여하기 위한 회사의 OKR 목표 관리와 결합하면 목표를 수집하는 동시에 다음과 같은 이점도 얻을 수 있다는 장점이 있습니다.

• 개인의 자기 동기를 고취하고 직원의 혁신과 성찰을 장려합니다.
• 상대적인 결과를 평가하고 어려운 도전과 돌파구를 장려합니다.
• 협력 기술을 평가하고 직원이 전방위적으로 협력하고 발전하도록 장려합니다.
Kubernetes는 오랫동안 인기를 끌었고 많은 기업에서도 이를 대규모로 적용하고 있습니다. 그러나 분명히 모든 기술이 만능은 아니며 모든 시나리오에서 문제를 해결할 수는 없습니다. 어떤 회사가 Kubernetes에 적합하지 않다고 생각하시나요? 그러한 회사의 모습과 그 이유를 설명해 주실 수 있나요?

Kubernetes는 지금까지 최고의 데브옵스 엔지니어링 애플리케이션 사례를 대표하지만(너무 맛있음) Youpaiyun의 CDN 엣지 서버, 데이터 센터 로그 분석 플랫폼, Ceph 분산 스토리지 등 모든 상황에 적용할 수는 없습니다. 물리적 기계. 따라서 다음과 같은 몇 가지 적합한 시나리오를 먼저 시도해 보는 것이 좋습니다.

사용량이 적은 기간으로 인해 시스템 리소스가 심각하게 낭비됩니다.

CPU, 디스크 및 네트워크 IO가 집중되지 않습니다.

• 소프트웨어 아키텍처가 마이크로서비스로 변화되었습니다.
• 비즈니스 처리 프로그램이 주기적이고 탄력적으로 확장됩니다.
• 귀사는 가장 가까운 파트너입니다. 일? 경계가 그려져 있나요? 또한 이 두 캐릭터를 긴밀하게 협력하는 방법에 대한 경험을 공유해 주실 수 있나요?

운영 및 유지 관리 엔지니어 = 전투에 돌격하는 일반 소프트웨어 엔지니어 = 전투 텐트에 앉아 있는 전략가

이론적으로 우수한 소프트웨어 엔지니어는 운영 및 유지 관리 엔지니어의 작업 중 일부(또는 전체)를 수행할 수 있습니다. 예를 들어 비즈니스 소프트웨어의 성능을 모니터링할 때 프로그래머가 프로그램에 많은 후크나 프로브를 삽입하면 운영 및 유지 관리를 위한 힘든 모니터링이 필요 없이 데이터를 계산할 수 있습니다. 프로그래머는 프로그램을 설계하고 분석을 고려합니다. 데이터베이스 샤딩은 대규모 동시성과 분산 설계를 고려하므로 소프트웨어에 버그가 많지 않으면 운영 및 유지 관리가 기계를 수평으로 확장할 수 있습니다. , 현실은 잔혹합니다. 특히 중국에는 모든 사람이 비즈니스 기능을 구현하느라 바쁘고 문서나 주석을 작성하는 것을 꺼리며 그것에 대해 철저하게 생각할 수 있는 수준의 프로그래머가 너무 적습니다. 마찬가지로 운영 및 유지 관리에 참여하는 많은 사람들은 훌륭한 오픈 소스 회사입니다. 매우 성숙한 소프트웨어이므로 훌륭한 소프트웨어가 어떻게 설계되었는지 배울 수 있습니다. . 표준 syslog 또는 로그를 통해 모니터링할 수 있습니다. 따라서 숙련된 운영 및 유지 관리는 다음을 수행합니다.

사전 계획에 적극적으로 참여하고, 개발 훈련에 협력하고, 배포를 자동화하고, 아키텍처 개선을 지원합니다.

합리적으로 요구 사항과 리소스를 높입니다. 문제가 발생하기 전에 예방하려면 예산이 있는 것이 좋습니다

온라인 모니터링, 결함 검토, 전체 팀에 대한 피드백, 상하위가 조율하고 개선하도록 강요

• 물론 위에서 언급한 역량을 달성하려면 운영 및 유지 관리에 있어서는 반드시 열심히 공부하고, 과거와 다음을 연결하고, 팀을 조정하고, 수년 동안 열심히 연습해야 할 것입니다. 그때쯤이면 운영 및 유지 관리는 더 이상 결과에 책임을 지지 않게 될 것입니다. 중요하지만 전체 프로세스를 주도하고 조정하는 역할로 역할을 바꾸십시오. 물론 여기서 말하는 능력이란 단순히 기술만 말하는 것이 아니라 사업을 이해하고 회사의 경영진 차원에서 전체 프로젝트와 자원의 배분과 통제에 직면할 수 있는 능력을 의미합니다. 따라서 운영 및 유지 관리 엔지니어는 실제로 소프트웨어 엔지니어를 보완하는 역할을 합니다. 사람마다 능력과 초점이 ​​다르기 때문에 모두가 하나로 뭉쳐야 전투에서 승리할 수 있습니다. 재배와 발전.
• 마지막으로 내 개인적인 의견: 건축가는 개인의 역할이 아니라 팀의 총칭일 수 있습니다.

전투에 뛰어들 필요는 없으며 전반적인 개요를 볼 수 있습니다. 모든 자원을 상황화하고, 전략을 세우고, 일정을 잡는다(운영과 유지) 아키텍트의 기능

팀을 이끌고 단결할 수 있으며, 거점을 구축하고 현재 상황에 따라 솔루션을 구현할 수 있다(소프트웨어 아키텍트의 기능)

파악할 수 있다 회사의 사업 방향과 깊이, 협력 협상, 비용 통제(사업부 비즈니스 아키텍처 기능)

• 운영 및 유지 관리는 각 팀의 목표와 관심사가 동일하지 않을 수 있으므로 여러 부서와 소통하고 협업해야 합니다. , 협력이 원활하지 않을 수 있습니다. 이 과정을 원활하게 만들기 위해 어떤 트릭을 사용하셨나요?

사실 의사소통이 잘 안되는 이유는 대부분 결과를 예측할 수 없기 때문입니다. 당신은 중복을 이야기하고 그는 구조를 이야기하고 그는 건설 기간을 이야기합니다. , 그러나 그 결과에 대해서는 누구도 책임을 지지 않습니다. 내 작업을 통해 문제가 발생하면 다양한 부서의 협력이 전례 없이 뭉치고 전투 효율성이 가장 강력하다는 것을 알았습니다. 따라서 의사소통과 협력의 핵심은 팀워크와 명확한 책임이 모두 필요하다는 것입니다

• 사전 부서 커뮤니케이션에서 프로젝트 기대치, 비용, 영향 요인, 실패 결과 및 책임 당사자를 결정합니다.
• 이후 실패를 검토할 때 실패 원인을 기반으로 한 합리적인 증거를 "비난"합니다. 동시에 경고를 받으십시오.

예를 들어 10W 온라인 동시성 기능을 제공하려면 중복 대역폭 중복 서버 x2가 필요하며 결과와 책임자는 예산을 절반으로 줄입니다. 예산 부족으로 인해 소프트웨어 설계가 불량한 경우 성능 모니터링을 통해 비정상적인 지표와 책임자의 결과가 발견됩니다. 물론 경보가 제때에 처리되지 않으면 사람의 작업 실패도 발생할 수 있습니다. 운영 및 유지 관리에 있어서 결함 문화는 사람이 아닌 문제와 사물 자체에 초점을 맞추는 것입니다. 누구나 실패를 통해 성장하고, 복습을 통해 더욱 강해진다.

운영 및 유지관리 업무에서 가장 중요한 목표는 무엇이라고 생각하시나요? 이러한 목표를 어떻게 달성했나요?

운영 및 유지 관리 자동화

정규화 모니터링

로그 시각화!

이 글은 너무 길어서 자세한 내용은 다루지 않겠습니다. "​​클라우드 운영 및 유지 관리의 계몽 및 아키텍처 설계​"

도구 선택, 자체 조사 여부를 참조하세요. , 오픈 소스 사용 또는 상용 제품 사용을 어떻게 선택합니까?

Youpaiyun은 일반적으로 바퀴를 재발명하지 않지만 반드시 바퀴를 먼저 사용하거나 더 편리하게 바퀴를 수정합니다. 자체 연구를 선택하는 경우 특정 개발 기능과 필요한 특정 이유가 결합되는 경우가 많습니다.

• 자체 개발한 클라우드 처리 소프트웨어 등 요구 사항을 충족하는 오픈 소스 소프트웨어를 찾을 수 없습니다...
• 오픈 소스 소프트웨어에는 커뮤니티가 단기적으로 발전할 수 없는 버그나 문제가 있지만 비즈니스가 시급하고 필요합니다. 예를 들어 ats의 메모리 누수 문제는...
• 오픈소스 소프트웨어의 기능적 특성이 회사 업무와 맞지 않아 nginx 같은 소프트웨어를 수정해야 합니다. 고객과 함께 맞춤화해야 하는 핫링크 방지 모듈...
• 오픈 소스 소프트웨어의 설계 목표는 너무 높고, 다재다능하지만 특정 작은 기능 포인트만 필요하다면 너무 부풀려집니다. 성능 프로브의 매설점과 같은 특별한 도구가 필요하지 않습니다...
• 데이터 보호 요구 사항이 있거나 개인 정보 보호가 있는 경우...

더 많은 기업이 퍼블릭 클라우드로 전환하고 있습니다. 클라우드 네이티브 아키텍처에서 SRE팀의 핵심 기능이 변경되었나요? 팀의 가치를 어떻게 강조해야 할까요?

퍼블릭 클라우드는 IaaS 기반, 컨테이너 클라우드는 CaaS 중간 계층, 클라우드 네이티브는 SaaS 애플리케이션 계층 역할을 합니다. SRE 팀의 핵심 기능은 날이 갈수록 변화하고 있습니다. 최상위 수준의 체계적인 용량 계획 및 지표 모니터링에 더 많은 관심을 기울이십시오. 따라서 플랫폼 간 및 부서 간 기능적 보완성, 팀 협업, 지속적인 개선 및 책임을 질 수 있는 용기에는 다음이 포함됩니다.

• 적극적으로 참여합니다. 사전 계획에서 개발 연습에 협력하고 아키텍처 개선을 지원합니다.
• 합리적인 개선 가용성 요구 사항, 중복 리소스, 문제가 발생하기 전에 미리 예산을 확보하는 것이 가장 좋습니다.
• 온라인 모니터링, 결함 분석, 피드백 팀 전체가 하향식 조정을 통해 개선을 강요합니다.

팀의 가치는 항상 새로운 것과 새로운 도전을 받아들이고, 자신의 강점을 활용하며, 우물 안의 개구리가 되거나 개구리를 끓이는 일을 피할 수 있습니까? 혁신이나 전복이 찾아오더라도 시대에 따라 분리될 수는 없습니다.

개별 운영 및 유지보수 엔지니어에게 SRE의 변화 경로는 무엇인가요? 무엇에 주의해야 합니까?

기술 분야

• 비즈니스 모델 추상화, 표준화된 구성 요소, 맞춤형 스크립트, 자동화된 배포를 배우고 전반적인 효율성을 향상시킵니다.
• 로그 수집, 로그 분석 및 시각화를 배우고 운영 및 효율성을 향상시킵니다. 유지 보수 모니터링 및 조기 경보
• 하나 이상의 언어를 익히고 익히면 전투 효율성이 향상되고 향상됩니다.
• 자주 메모하고, 과거를 검토하여 새로운 것을 배우고, 학습과 사고를 결합하세요. 축적하려면 하나의 예에서 추론하세요.
• 새로운 기술에 맞설 만큼 용감하세요. 도전을 이길 수 없다면 배워보세요.

비기술 분야

• 학습 능력에는 폭넓은 지식이 필요합니다.
• 커뮤니케이션 측면에서 고객의 정확한 요구 사항을 이해합니다.
• 기술적 위험, 노동, 일정 및 기타 비용을 고려하고
• 커뮤니티 활동, 적극적으로 공유하고 웅변을 발휘합니다.
• 영향력을 키우고, 다른 사람들과 함께 걷는 법을 배우고, 더 많은 친구를 사귀세요.

현재 기초 기술의 급속한 발전에 직면하여 이제 막 업계에 들어온 운영 및 유지 관리 인력에 대해 어떻게 생각하십니까? 그리고 오랫동안 업계에 종사하신 분들의 진로 계획에 대한 조언이 있으신가요?

일단 사람을 선택하는 것은 직업이 아니라 사람이 선택하는 것입니다. 어떤 분야에 관심이 있고 10,000시간 가까이 정말 열심히 공부했다면 그 사람은 실제로 무엇이든 할 수 있습니다. . 예를 들어, 제가 졸업할 때 복합적인 재능에 중점을 두었고 운영 및 유지 관리 같은 것이 없었습니다. 우리는 기계를 만들고(DIY) Linux 운영 체제를 스스로 가르쳤을 뿐만 아니라 프로그래밍도 배웠습니다. Linux는 매일 우리에게 혁신적이고 재미있으며 우수한 오픈 소스 소프트웨어를 제공하여 기회가 오면 마음껏 배우고자 하는 열정을 유지할 수 있도록 해줍니다. 인터넷이 부흥하면서 운영 및 유지 관리 책임자가 되는 것이 실제로 논리적입니다. 사실 이 외에도 사전 판매 및 기술 지원으로 전환하고 시장을 방문하고 연설 교육도 자주 했습니다. , 진정한 마스터는 아무것도 배울 수 없습니다. 그는 많은 기술을 가지고 있지만 개발할 수 있는 운영 및 유지 관리 엔지니어를 압도하지 않습니다.

운영 및 유지보수 인력에게 가장 중요한 자질은 무엇이라고 생각하시나요? 업계에 새로 입사하는 운영 및 유지보수 인력에게 어떤 메시지를 전하시겠습니까?

가장 중요한 능력은 표현력과 소통능력이라고 생각하는데, 운영과 유지관리 자체에 필요한 기술적 예비력, 실무 능력, 프로그래밍 능력, 학습 능력도 배제되지 않습니다. 운영 및 유지 관리가 여전히 대부분 비용 지출 위치라는 점을 고려하면, 상위 경영진의 지속적인 투자를 얻기 위해 난해하고 모호한 성능 및 병목 현상 지표를 직관적인 차트 표시에 사용하는 방법은 기술이 필요하며 동료 및 형제 부서와도 마주해야 합니다. 일을 조정하고 추진하려면 영향력이 필요합니다. 이렇게 할 수 있다면 앞으로 하는 모든 일에서 더 높은 수준에 있게 될 수 있도록 이끌 수 있는 능력이 있다는 뜻이며, 전체적인 관점에서 조정을 하게 됩니다. 전체 프로젝트를 계획하고 목표, 인력, 건설 일정 및 자원을 합리적으로 할당합니다.

위 내용은 Yun Shao Haiyang의 또 다른 장면: 25년 경력의 Linux 베테랑이 DevOps의 8가지 명예와 8가지 불명예에 대해 이야기합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!