모든 프로그래머가 알아야 할 sysadmin 항목은 무엇입니까?


96

프로그래머로서 우리는 시스템 관리자를 당연한 것으로 여깁니다. 좋은 sysadmin이 없었던 몇 번은 정말 당신들이하는 일에 감사하게 만들었습니다. 시스템 관리자가없는 환경으로 환기 할 때 어떤 지혜의 말을 우리에게 제공 할 수 있습니까?

답변:


70

나는 시작할 것이다 :

  1. 항상 어떤 종류의 백업 시스템이 있습니다. 역사가 있다면 더 좋습니다.
  2. 단일 실패 지점과 실패시 처리 방법을 고려하십시오.
  3. 컴퓨터 수에 따라 컴퓨터 전체에서 표준 이미지를 만들고 생성 할 수있는 방법을 모색하면 모든 사람의 삶이 더 쉬워 질 것입니다. 이러한 프로그램이 설치되어 있지 않기 때문에 "내에서 작동하지 않습니다".
  4. 이 때문에 경우에만, 모든 것을 문서화 할 것이다 당신이 뭔가를 위로 설정하는 방법을 잊는다.
  5. 보안 업데이트를 확인하십시오.

11
모든 단계를 문서화하는 것은 좋은 시스템 관리자가하는 일이며 직접 시작했습니다. 정말 도움이되었습니다.
Nathan DeWitt

2
자체 문서화 시스템을 고려하십시오. 예를 들어, 주석이 달린 Zone 파일이 정식 정보 소스 인 경우 텍스트 파일 또는 위키에 호스트 이름 목록을 유지해야하는 이유는 무엇입니까?
Dave Cheney

3
데이브, 잘 정리 된 존 파일은 누구나 접근 할 수 있습니까? 내가 새로 온 사람이라면 "모든 곳에서 문서화되는 것보다는"모든 답변을 위해이 위키로 가십시오 "라고 말하는 것이 쉽지 않습니다. DNS는 DNS 설정에 문서화되어 있습니다. whozit는 whozit에 문서화되어 있습니다 구성 파일. 데이터베이스는 데이터베이스 구성 파일에 문서화되어 있습니다. " 그것은 매우 나에게 비우호적 인 것 같습니다.
Nathan DeWitt

5
Nathan, Dave : 트릭은 물론 정식 소스에서 위키를 업데이트하기 위해 스크립트를 사용하는 것입니다. 그것은 나를 위해 경이로움을 느꼈습니다. 지금 일하는 곳에서는 사용할 수 없어서 정말 죄송합니다.
Anders Eurenius

6
테스트 시스템을 구축하십시오. 실패가 옵션 인 환경이 필요합니다. 이를 위해 VirtualBox를 실행하는 서버가 있지만 서버를 사용할 수없는 경우 개인 워크 스테이션을 사용했습니다
Mark Porter

44

<큰 게시물 면책 조항을 여기에 삽입>

이들 중 일부는 이전에 언급되었지만 반복 할 가치가 있습니다.

문서:

  • 모든 것을 기록하십시오. 레이더가없는 경우 Under-the-Radar 위키를 설치하되 백업하십시오. 사실을 수집하는 것으로 시작하면 언젠가 큰 그림이 형성됩니다.

  • 각 논리적 청크에 대한 다이어그램을 작성하고 업데이트하십시오. 정확한 네트워크 맵이나 클러스터 다이어그램이 저를 구한 횟수를 셀 수 없었습니다.

  • 시스템 구축 방법에 대한 명령을 복사하여 붙여 넣더라도 각 시스템에 대한 빌드 로그를 유지하십시오.

  • 시스템을 구축 할 때 앱을 설치 및 구성하고 작동 여부를 테스트하고 벤치마킹을 수행하십시오. 이제 디스크를 닦으십시오. 진심으로. 디스크 앞면의 첫 번째 메가 바이트를 'dd'로 설정하거나 상자를 부팅 할 수 없게 만듭니다. 시계가 똑딱 거리고 있습니다. 문서가 처음부터 다시 작성 될 수 있음을 증명하십시오. 이것은 재해 복구 계획의 절반을 구성합니다.

  • 이제 재해 복구 계획의 전반부는 나머지 부분을 문서화합니다. 응용 프로그램의 상태를 복구하는 방법 (테이프에서 파일 복원, 덤프에서 데이터베이스 다시로드), 공급 업체 / 지원 세부 정보, 네트워크 요구 사항, 교체 하드웨어를 얻는 방법 및 위치 등 시스템을 백업하는 데 도움이 될 수있는 방법

오토메이션:

  • 최대한 많이 자동화하십시오. 세 번 무언가를해야한다면, 두 번째는 자동화를 개발하는 데 소비되므로 세 번째는 완전히 자동화되어야합니다. 자동화 할 수 없으면 문서화하십시오. 자동화 제품군이 있습니다. 여러분에게 적합한 자동화 제품군이 있는지 확인하십시오.

모니터링 :

  • 응용 기기는 순금입니다. 시스템을 통과하는 트랜잭션을 볼 수 있으면 디버깅 및 문제 해결이 훨씬 쉬워집니다.

  • 응용 프로그램이 살아 있음을 증명할뿐만 아니라 실제로 예상되는 기능을 수행하는 종단 간 테스트를 만듭니다. 경고 목적으로 모니터링 시스템에 연결될 수있는 경우 포인트를 사용하십시오. 이것은 이중 의무를 수행합니다. 앱의 작동을 증명하는 것 외에도 시스템 업그레이드가 훨씬 쉬워집니다 (모니터링 시스템 보고서는 친환경, 업그레이드가 완료되었으며 집에 갈 시간).

  • 모든 제정신의 모든 것에 대한 지표를 벤치마킹, 모니터링 및 수집합니다. 벤치 마크는 언제 마법 연기가 나올지 예상 할 때 알려줍니다. 모니터링이있을 때 알려줍니다. 지표와 통계를 통해 관리를 통해 새로운 키트 (신선한 연기가 나는 연기)를 쉽게 얻을 수 있습니다.

  • 모니터링 시스템이없는 경우 모니터링 시스템을 구현하십시오. 실제로 위의 엔드-투-엔드 테스트에 잭을 연결하면 보너스 포인트가 적용됩니다.

보안:

  • "chmod 777"(일명 모든 액세스 / 권한 부여)은 해결책이 아닙니다.

  • '최소 비트'원칙에 가입하십시오. 디스크에 설치, 복사 또는 저장되어 있지 않으면 손상 될 수 없습니다. "주방 싱크대"OS 및 소프트웨어 설치로 인해 빌드 단계에서 생활이 쉬워 질 수 있지만 결국에는 비용을 지불하게됩니다.

  • 서버의 모든 열린 포트가 무엇인지 알고 있어야합니다. 새로운 것을 나타내지 않도록 자주 감사하십시오.

  • 손상된 서버를 정리하지 마십시오. 처음부터 다시 작성해야합니다. 새로 다운로드 한 미디어를 사용하여 예비 서버로 재 구축 (이진이 손상되었을 수있는 백업) 된 데이터 만 복원하거나 분석을 위해 격리 된 곳으로 손상된 호스트를 복제하여 동일한 키트에서 재 구축 할 수 있습니다. 이 문제에 대해 법적인 악몽이 있기 때문에 법적인 길을 찾아야 할 경우를 대비하여 보존 측면에서 잘못하십시오. (참고 : IANAL).

하드웨어:

  • 상자에 표시된 내용을 수행 할 것이라고 가정하지 마십시오. 필요하지 않은 경우를 대비하여 필요한 것을 수행하십시오. "거의 작동"이라고 생각하는 것보다 더 자주 말하는 것을 알게 될 것입니다.

  • 원격 하드웨어 관리를 방해하지 마십시오. 직렬 콘솔 및 소등 관리는 필수로 간주해야합니다. 옵션이 없을 때 원격 제어 전원 스트립의 보너스 포인트.

(외부 : 오전 3시에 문제를 해결하는 두 가지 방법이 있습니다. 하나는 따뜻하게하고, 잠옷의 VPN을 통해 랩톱에서 작업하고, 다른 하나는 두꺼운 재킷과 데이터 센터 / 사무실 드라이브를 포함합니다. 취하다.)

프로젝트 관리:

  • 프로젝트 수명주기 중 첫 날부터 시스템을 유지 관리 할 사람들을 참여시킵니다. 키트 및 브레인 타임에 대한 리드 타임은 놀라 울 수 있으며 놀라게 될 것이며, 프로젝트 종속성이 될 표준 또는 요구 사항이있을 것입니다.

  • 문서는 프로젝트의 일부입니다. 프로젝트가 종료되고 시스템이 유지 보수로 이동 한 후에는 전체 내용을 기록 할 시간이 없으므로 시작시 일정에 노력이 포함되어 있는지 확인하십시오.

  • 첫날부터 계획된 노후화를 구현하고 프로젝트 문서에서 지정한 종료일 6 개월 전에 새로 고침주기를 시작하십시오.

서버는 프로덕션 환경에서 사용하기에 적합한 수명을 갖습니다. 이 수명의 종료는 일반적으로 공급 업체가 키트를 새로 고치는 데 드는 비용보다 3 년 중 더 짧은 기간 동안 연간 유지 보수에서 더 많은 비용을 청구 할 때마다 정의됩니다. 이 후에는 개발 / 테스트 환경에 적합하지만 비즈니스 운영에 의존해서는 안됩니다. 2 년 반에 환경을 다시 방문하면 새로운 키트를 주문하는 데 필요한 관리 및 재정 지원을 통해 많은 시간을 할애 할 수 있으며, 오래된 키트를 하늘의 큰 공급 업체에 보내기 전에 원활한 마이그레이션을 구현할 수 있습니다.

개발:

  • 개발 및 스테이징 시스템이 프로덕션과 유사해야합니다. VM 또는 기타 가상화 기술 (영역, LDOM 및 가상 서버)을 사용하면 실제와 동일하지만 성능이 뛰어난 프로덕션 클론을 쉽게 만들 수 있습니다.

백업

  • 백업하지 않는 데이터는 원하지 않는 데이터입니다. 이것은 불변의 법칙입니다. 당신의 현실이 이것과 일치하는지 확인하십시오.

  • 백업은보기보다 어렵습니다. 일부 파일은 열리거나 잠겨있는 반면 복구 할 수 있으려면 다른 파일을 일시 중지해야하며 이러한 모든 문제를 해결해야합니다. 일부 백업 패키지에는 열려 있거나 잠겨있는 파일을 처리하는 에이전트 또는 기타 방법이 있지만 다른 패키지에는 없습니다. 데이터베이스를 디스크에 덤프하고 백업하는 것은 "정지"의 한 형태로 간주되지만 유일한 방법은 아닙니다.

  • 테스트를 거치지 않으면 백업은 쓸모가 없습니다. 몇 개월마다 아카이브에서 임의의 테이프를 꺼내 실제로 데이터가 있고 데이터가 일관성이 있는지 확인하십시오.

그리고 가장 중요한 것은 ...

실패 모드를 선택하십시오. 그렇지 않으면 Murphy는 ... 스케줄에 따라 작동하지 않습니다.

장애에 대한 설계, 각 시스템의 설계 취약점, 그 원인 및 복구 방법을 문서화하십시오. 무언가 잘못되었을 때 모든 차이를 만들 것입니다.


1
한 사람이 내 마음을 들여다 것입니다 - 그것은 아름다웠다; P
오스카 Duveborn

3
"정상적인 모든 일에 대해 벤치 마크, 모니터링 및 메트릭 수집 연기)) 관리를 통해. " 순금
TJ Crowder

43

쉬운 것으로 가정하지 마십시오. 필자는 웹 팜을 실행할 수있는 IIS 나 Apache를 설치할 수 있다고 생각하는 많은 프로그래머를 알고 있습니다. 업무와 관련된 사항을 이해하고 연구 및 계획을 수행하십시오. sysadmin 작업이 10 분 안에 앱을 배포하기 위해 할 수있는 쉬운 일이라고 생각하지 마십시오.


7
이것을 위해 +1. 실제로는 쉽게 보이기 때문이 아닙니다 .
Gert M

관리자와 프로그래밍 작업을 모두 수행하는 일반인으로서 귀하의 어려움을 완전히 이해하고 있습니다. +1
Avery Payne

4
물론 다른 방식으로 진행됩니다. 필자는 스크립트 종류와 작은 유틸리티 프로그램의 차이점을 이해하지 못하는 몇 가지 sysadmin 유형을 발견했습니다.
Rob Moir 2016 년

2
+1 Robert : 또는 시스템 관리자가 잘못 설계된 네트워크 아키텍처를 해결하기 위해 "간단한 if 문"이라고 말합니다. 상호 존중과 이해가 핵심입니다.
Steven Evers

27
  • 더 좋든 나쁘 든 많은 서버 및 / 또는 네트워킹 장비는 다른 가족의 자녀와 매우 유사하다는 것을 인식하십시오. 이들은 그들의 아기입니다. 그들은 그들을 돌보고 병이 들었을 때 그들을 돕고, 문제가 있는지주의 깊게 모니터링합니다. 이것은 이 방법이 될 수 있지만, 몇 년 후, 그것은 종종있다 . 장비가 제대로 작동하지 않거나 기대하는 것에 대한 우려를 전달할 때이 점을 명심하십시오. 이해할 수없는 답장이 있으면이 세계관을 통해 필터링 해보십시오.
  • 좋은 근무 조건을 유지하십시오. 기운이 들리지만 금의 무게는 가치가 있습니다. 언젠가는 특별한 호의가 필요합니다. 그리고 언젠가는 sysadmin이 단 한 번만 인생을 좀 더 편하게 해줄 수있는 방법으로 기쁠 것입니다.
  • 그 일하는 관계는 두 가지 방식으로 진행됩니다. sysadmin이 매우 바쁘고 작은 스크립트 나 프로그램을 작성하여 삶을 조금 더 쉽게 만들 수 있다면 그렇게하십시오! 그들은 당신이 아는 것보다 더 감사 할 것입니다.
  • 매우 명확해야합니다. "간헐적 인 네트워크 연결이 약간 성가시다. 당신이 그것을 볼 수 있을까?"
  • 앱이 확장됩니다 생각한다면, 전에 관리자에게 가정 은 것이다. 그렇지 않은 것을 "보거나"배치 할 장비의 성능 한계에 대해 알고있을 수 있습니다.
  • 앱을 조정해야하지만 코드 문제가 아닌 것으로 보이는 경우 서버의 성능에 대해 잘 문의하십시오. Sysadmin은 컴퓨터를 사랑스럽게 돌보는 경향이 있으며 "병"또는 "잘못 동작"할 때 기뻐하지 않습니다. 잘 부탁하면 병든 기계를 돌리거나 수리 / 교체하게됩니다.
  • (다른 곳에서 언급했듯이) 사용하는 설정과 사용 이유 를 문서화하십시오 . "확인란 X 설정"또는 "구성 해제 주석 파일 줄 Y"만 있으면 도움이되지 않습니다. 다음에 다시 부팅 할 때 아는 모든 데이터를 지우는 옵션을 설정할 수 있습니다.
  • 용지에 설정을 문서화 할 시간이 없으면 가능한 경우 시스템에 문서화하십시오. 설정 파일, 이것은 거의 표준 관행이어야한다 - 모든 설정 변경, 날짜가 표시된해야 이니셜로, 해당 설정의 예상 효과 및 이유 이유 가 변경되었습니다 (이전 글 머리 참조). 이 작은 습관은 바삭 바삭 시간 동안 베이컨을 두 번 이상 절약했습니다. "왜 그렇게 했습니까?" "우리는 정책 X를 의무화했기 때문에 Y를 설정하면 정책 X에 필요한 동작이 제공됩니다."
  • 맥주. 또는 콜라. 또는 심지어 물. 음료는 항상 환영합니다. sysadmin이되는 것은 목 마른 일입니다.

3
구성 파일 설명서 / 변경 문제의 경우 모든 구성 파일을 버전 제어 시스템에 배치하는 것이 좋습니다. 프로그래머가 소스 코드에 이미 그러한 시스템을 사용하고 있기 때문에 프로그래머가이 작업을 매우 쉽게 수행 할 수 있어야합니다. 변경 사항을 커밋 할 때마다 의견을 추가하면 기록으로 돌아가서 변경된 내용과 이유를 쉽게 확인할 수 있습니다.
Anders Sandvig

변경 관리시 "루프를 닫습니다". 좋은 제안.
에이버리 페인

2
명확한 오류 보고서를 제공하기위한 훌륭한 제안. 문제가 있다는 말을 듣고 좌절을 느끼는 것은 없으며 많은 사람들에게 영향을 줄 수 있다는 사실을 알고 있기 때문에 관심이없는 프로그래머의 세부 사항을 애타게해야합니다
Dave Cheney

23

보안은 나중에 생각할 것이 아닙니다. 해킹 된 앱은 프로그래머를 무능하게 보이게 할 수 있지만 적어도 sysadmin의 백업을 확인, 정리 및 / 또는 복원하는 데 소비 한 주말은 잃어 버렸습니다.

따라서 백업을 버전 관리로 취급하지 마십시오. 그것들은 재난 복구를위한 것이며 변경 한 것을 잊었 기 때문에 코드를 복원하도록 설계되지 않았습니다.

코드가 손상되었다고 맹목적으로 Windows Update를 비난하지 마십시오. 나는 그것이 잘 작동하지 않았는지, 왜 지금 작동하지 않는지 말해주십시오-그러면 우리는 누구의 잘못인지 알 수 있습니다.


17

네트워킹 문제를 디버깅하고 sysadmin 도구로 프로그램이 실행되는 것을 보는 방법 시스템 관리를 시작한 프로그래머 인 저는 네트워킹이 일단 중단되면 많은 프로그래머가 무능한 사람이 된 것에 놀랐습니다.

  • 패킷별로 패킷을 블랙 박스 방식으로 실행하는 Wireshark
  • 네트워크 서비스에 직접 연결하는 도구 :
    • TCP 또는 UDP를 통한 일반 연결을위한 Telnet, netcat 또는 socat
    • openssl s_client -connect target-host:port네트워크 서비스에 수동으로 연결하기위한 암호화 (힌트 : 언젠가 시도 ) 와 동일한 것에 대한 OpenSSL
  • 이름 확인 디버깅을위한 dig (BIND 9 패키지)
  • 실패한 연결의 타이밍 및 기타 특성을 기반으로 네트워크 스택의 어떤 부분이 실패했는지 알 수 있음
  • 아마도 HTTPFox 및 / 또는 Firebug

3
+1. 견고한 네트워크 성능에 의존하는 응용 프로그램을 작성하는 개발자는 코드 작성을 시작하기 전에 W. Richard Stevens의 'TCP / IP Illustrated v1'을 읽어야합니다.
Murali Suriar

1
모든 유능한 분들 감사합니다. 기본 네트워킹이 실패하면 프로그래머가 무력한 정지 상태에서 몇 년 동안 나를 놀라게했습니다. 요즘 거의 모든 프로그래밍은 네트워크 프로그래밍입니다.
jhs 2009

14

문제 해결 방법을 알고 있어야합니다.

벅을 통과하는 것은 매우 쉽습니다 (예 : 네트워크가 데이터베이스와의 통신을 원하고 있습니다). 네트워크 오류 일 수 있지만 Google 또는 SO를 사용하는 경우 앱 구성에 문제가있을 수있는 오류가있는 응용 프로그램 로그가 있어야합니다.

모두가 하드웨어, OS 또는 네트워크를 비난하는 것을 좋아하므로 조금 더 실사를하면 sysadmin을 행복한 사람으로 만들 수 있습니다. 다른 것이 없다면 "네트워크가 짜증나거나 다른 도움이된다"고 말하는 것과는 반대로, 잘못된 방향에 대해 특정 방향으로 지시 할 수 있기 때문입니다.


1
물론. 사람들이 잘못된 방향으로 나를 가리켜 서 잘못된 장소에서 문제를 찾는 데 걸린 시간을 셀 수 없습니다.
Gert M

8

할 수있는 모든 것을 기록하십시오. 마지막 sysadmin이 '작업 보안'을 위해 무언가를 문서화하지 않거나 누군가가 그냥 나가고 싶어하는 것이 귀엽다고 생각한 횟수를 말할 수 없습니다. 프로그래머가 좋은 의견을 남기 듯이 sysadmins도 문서를 작성해야합니다. 토폴로지 다이어그램도 좋습니다.


7

계획 B.

솔루션을 설계하고 개발할 때는 항상 재해 복구 계획을 염두에 두십시오. 중단으로 이어질 수있는 단일 장애 지점을 인식합니다.


6

설명서 : 문제를 해결할 필요가 없지만 응용 프로그램 작동 방식, 비트가 어떻게 적용되는지, 각 구성 요소가 모두 잘못되었을 때 테스트하는 방법을 보여주는 다이어그램. 샘플 데이터 및 출력이 좋습니다.

요구 사항 : 어떤 모듈에 의존합니까? 버전? OS?

모니터링 : 이상적으로 개발자는 응용 프로그램으로 모니터링 정보 및 테스트를 포함합니다.

포장이라고하면 포장! "배치"보다 나쁘지 않은 것은 VCS에서 파일의 새로운 개정판을 확인하고이를 여러 서버에 복사하는 것을 의미합니다. 프로그래머가 소프트웨어 배포의 복잡성을 인식하지 못하는 경우가 많습니다. 버전이 지정된 패키지 소프트웨어가 대부분의 OS의 백본을 형성하는 이유가 있습니다.

개발자가 간결하고 포괄적 인 문서와 일부 Nagios 테스트를 통해 처음 설치 한 RPM을 사용하게되면 저의 새로운 친구가 될 것입니다.


6

지금까지 17 가지 답변 중 표준 사용자로 로그온 할 때 응용 프로그램이 실행되도록하는 것에 대한 모든 답변이 포함되어 있다는 사실에 놀랐습니다.

설치 프로세스 외에 표준 사용자 계정으로 로그온하면 응용 프로그램이 제대로 실행됩니다.



4

이것은 초보 프로그래머에게만 적용될 수 있지만 모든 프로그래머는 일부 프로젝트에서 몇 가지 사항을 처리합니다.

  1. "그것은 내 컴퓨터에서 작동합니다"는 유효한 진술이 아닙니다. 서버에서 사용할 설치 프로그램을 만들거나 최소한 서버에 필요한 모든 연결과 dll 및 추가 기능을 문서화하는 것은 프로그래머의 책임입니다.

  2. (이걸 여러 번 들었으므로 웃지 마십시오.) 내 컴퓨터에서 서버에서 exe를 실행하면 작동합니다. 그러나 서버 (Citrix, Terminal Server 등)에서 실행하면 작동하지 않습니다. dll 및 ocx 및 프로그램에 필요한 기타 사항과 등록 위치 및 방법, 프로그램 사용 방법을 이해하십시오.

이것들은 단순 해 보일지 모르지만 나는 끊임없이 그것을 다루고 있습니다.

브라이언


4
  • 현재하고있는 일에 대해 정식 및 비공식적으로 관리자에게 문의하십시오. 그들은 일반적으로 관심이 있고 생산 초기에 가능한 영향을 표현할 수 있습니다. 동의 할 필요는 없지만 문제 지점을 식별하는 데 도움이됩니다.
  • 아니요, 전체 서버를 직접 소유 할 수는 없습니다 ... 필요한 경우 기술적으로 얼마나 건전한 지에 상관없이 정치적 결정입니다. 정치를하고 싶다면 바로 가십시오.
  • 프로덕션 하드웨어는 종종 개발 서버와 다르게 보이고 심지어 팜 내에서도 시스템 사양이 다릅니다.
  • 데스크탑에서 프로덕션을 복제 할 수 없기 때문에 프로덕션 설정 방법을 배우십시오. 이렇게하면 가정이 잘못 될 수 없습니다.
  • 메모리에 내용을 캐시 할 수 있다고해서 반드시 병목 현상이 발생할 때까지 기다릴 필요는 없습니다 (단위 테스트 또는 사전 프로덕션 성능 테스트에서)
  • 데이터베이스에서 데이터를 고수하는 경우 데이터를 읽기 전용 데이터 (수평 확장 가능)와 읽기 / 쓰기 데이터 (일반적으로 수직 확장 가능)로 분리하는 방법을 고려하십시오.
  • 데이터베이스에 데이터를 고정시키는 경우 실제로 RDBMS 여야합니까? 더 나은 확장 성을 제공하는 다른 키-값 페어 시스템이 있습니다 (netcache).
  • AJAX가 최첨단 솔루션이라고 생각하지 마십시오. 멋지지만 모니터링 및 자동화 가능성을 제한합니다. 나는 그것을 사용하지 말라고 말하는 것이 아니라 두 번 생각하십시오.

4

좋아, 이것은 약간 삐걱 거리지 만 :

a) 코딩 할 때 기본 인프라가 실패 할 수 있고 행복하고 상시 상륙하지 않는 것으로 가정합니다. 아니면 구글.

b) 우리는 아마도 당신이 읽은 인프라와 같은 것을 구현할 자원이 없을 것입니다. 우리는 무엇을해야할지 알지만, 어떤 이유로 든 아직 일어나지 않았습니다. 우리는 당신의 파트너입니다!

c) 위에서 언급 한 jhs처럼 ping, traceroute (또는 mtr 결합 또는 mtr 결합), 발굴 등과 같은 인프라 문제를 해결하는 도구에 정통한 사용자라면 실제로 도움이 될 것입니다.

d) 컴퓨터를 프로그래밍하는 경우 실제로 컴퓨터가 네트워크에 연결되는 방법과 ipconfig / all 또는 ifconfig의 출력을 구문 분석 할 수있는 것과 같은 기본 사항을 알아야합니다. 최소한의 도움으로 인터넷 연결을 설정하고 실행할 수 있어야합니다.

그렇지 않으면 Avery가 거의 그것을 못 박았다고 생각합니다. 약간의 sysadmin을 수행하는 개발자는 금의 무게가 가치가 있습니다! 그러나 마찬가지로, 개발자가 버전 관리 등을 어떻게 처리하는지 이해하는 시스템 관리자는 오늘날에도 매우 중요합니다.

이것은 현재 방송중인 것 같습니다. 블로그의 개발자 / 운영자 관계에 대한 추가 토론이 있음을 확인했습니다.

트위터 트위터 유지

파티션과 전쟁

운영에서 먼저 테스트


3

어떤 그룹이나 기능이 다른 것보다 '더 나은'것은 아니며, 다른 것보다 더 큰 두뇌를 필요로하지 않는 것입니다. 나는 상대방의 회사에서 두 가지 측면이 모두 원동력을 얻는 것을 보았습니다. 모두 같은 목표를 달성하려고 노력하고 있습니다. 다른 도구를 사용한다는 사실이 아니라 이러한 유사점에 초점을 맞추십시오.


2

인프라 아키텍트는 프로그래머가되어 미래에 그 트랜잭션을 롤백하고 싶을 수도 있습니다. :)

  1. 일찍 그리고 자주 서로 대화하십시오. 앱이 배포 될 인프라를 관리 할 담당자와 디자인을 검토합니다 (누군가를 알고 있는지).
  2. 제로 데이터 손실은 가능하지만 개발자와 시스템 관리자가 공유하는 책임입니다. 다시 말하면 서로 이야기하는 것이 도움이 될 수 있습니다.
  3. 비 기능 요구 사항을 결정하는 데 인프라 직원이 참여해야합니다.
  4. 맥주 (작업이 완료 될 때)와 피자 (작업하는 동안)를 준비하십시오. 어쨌든, 그런 종류의 음식의 존재는 우리의 멋진 32 개의 cpu 상자가 원하는대로 할 수있게하는 우리의 능력에 영향을 미칩니다. :)

2

개발자를위한 시스템 관리자이자 개발자 인 본인으로서 여기에 제공된 조언은 금일뿐만 아니라 회사 전체의 새로운 개발자를위한 채용 문서의 일부 여야합니다.

내가 보지 못했지만 (아직도) 설명하지 않은 것은 개발자가 유료 프로그램을 만드는 데 사용할 제품을 실제로 알아야한다는 것입니다. 개발자 컴퓨터에서 아파치 서버, 이클립스 및 Visual Studio 설치 및 데이터베이스를 설명하고 구성 해야하는 시간은 약간 걱정입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.