문제

얼마 전에 저는 지금까지 작업 한 거의 모든 고객 프로젝트가 중요한 이해 관계자 그룹 인 시스템 관리자를 무시했다는 것을 깨달았습니다.

이 조용한 영웅들은 일반적으로 프로젝트가 끝날 때만 관여하며 앞으로 몇 년 동안 설치, 지원 및 유지 해야하는 실행 가능한 블랙 박스가 남아 있습니다. 이 블랙 박스에서 문제가 발생할 때마다 블랙 박스 나 기본 플랫폼에서 제공하는 임의의 정보 및 도구 지원을 사용하여 해결할 수있는 방법을 찾아야합니다. .

그들이 처음부터 프로젝트에서 이해 관계자로 참여했다면 잠재적 인 문제를 예측하고 프로젝트 팀에 이에 대해 알릴 기회가 있었을 것입니다. 그러나 현실은 다르며 개발자로서 시스템 관리자를 추가 이해 관계자로 참여시키기를 원하지만 외부 요인으로 인해 이런 일이 발생하지 않을 수 있습니다.

이러한 상황에서 나는 우리의 조용한 영웅을 최대한 잘 돕고 싶습니다. 그래서 내 질문은 다음과 같습니다.

시스템 관리자는 관리해야 할 시스템을 개발할 때 개발자의 무엇을 원할까요?

시스템 관리자 인 경우 전쟁 이야기를 들려주세요 한때 어려운 문제와 개발자가 쉽게 해결할 수 있도록 개발자가 할 수있는 일에 대해.

도움이 되었습니까?

해결책

우선 순위에 있지 않은 것들을 포함하여 (그러나 제한되지 않을 것임) 다양한 것들.

  • 권한있는 설치를 사용할 필요가 없습니다
  • 권한있는 설치 옵션
  • 분산 설치 옵션 (따라서 서버에 설치하고 다른 기계에서 사용할 수 있음)
  • 제거 해제하십시오
  • 현명한 업그레이드 패턴
  • 설치 위치를 선택하는 옵션
  • 다른 소프트웨어에 대한 최소 의존성
  • 시스템 주변의 데이터의 최소 산란 ( /etc, /usr /lib, /var /adm, ...)에 물건을 버리지 마십시오.
  • 끊임없이 성장하는 통나무가 없습니다
  • 조용한 설치
  • 스크립트 설치
  • 온라인 문서 (인터넷뿐만 아니라 기계에서)
  • 아마도 맨 페이지
  • 구성하기 쉽습니다
  • 최종 사용자가 쉽게 액세스 할 수 있습니다
  • 보안 위험이 없습니다
  • 특별한 사용자 또는 그룹 (또는 제한된 번호 - 최대 한 명의 특별 사용자, 하나의 특별 그룹은 목표는하지만 항상 달성 할 수있는 것은 아닙니다).
  • '전화 주택'기능이 없거나 명시 적으로 구성된 경우에만 (기본값이 아니어야합니다)
  • 문제가있을 때 진단의 좋은 기록
  • 문제가있는 경우 좋은 기술 지원이 가능합니다
  • 설치 중에 활성화 코드를 가져올 필요가 없습니다
  • 설치 후 기계를 재부팅 할 필요가 없습니다
  • 구식 및 새 버전을 병렬 실행 능력

소프트웨어가 무엇인지, 사용 방법에 따라 다릅니다. Windows, Linux 및 MacOS X에서 작동하는 GUI 프로그램의 요구 사항은 네트워크 데몬의 요구 사항과 근본적으로 다르지만 목표는 여전히 안정적이고 신뢰할 수 있으며 쉽게 관리되는 소프트웨어 여야합니다.

한 회사 내에서 사용하기 위해 사내 부서에서 준비한 소프트웨어와 소프트웨어를 개발하는 회사 외부 고객이 사용할 수 있도록 준비한 소프트웨어간에 큰 차이가 있음을 명심하십시오.

다른 팁

문제가 불가피하게 발생하면 Sysadmin이 말한 것에주의를 기울이고 그를 믿습니다. 초기 평가에 맞지 않으면 손으로 무시하지 마십시오.

전쟁 이야기 : 약 6 년 전, 저는 소규모 제조 회사를 위해 Sysadminning을했으며 장비의 예방 유지 보수 일정을 처리하기 위해 소프트웨어를 구입하기로 결정했습니다. 그 기능 중 하나는 이메일에서 유지 보수 요청을 가져 오는 것이었지만이 프로세스 중에 메일 서버와 대화하는 오류에 가끔 문제가 발생했으며 결국 개발자와 전화를 걸고있는 동안이를 살펴 보도록 요청 받았습니다. 대화에는 여러 번의 반복이 포함되었습니다

개발자 : 나는 메일 서버와 대화하는 데 어려움을 겪는 사람은 누구도 들어 본 적이 없습니다. 방화벽 문제 여야합니다.

나 : 방화벽에 로그인하여 패킷 스나이퍼를 실행하고 문제없이 앱의 트래픽이 통과되는 것을 지켜보고 있습니다. 방화벽을 통과하고 있습니다.

개발자 : 아니요 - 아니요 - 방화벽 문제 여야합니다.

(결국, 문제는 앱이 POP3 연결을 열고, 모든 메일을 읽고, 사용자가 작업을 예약하기를 기다린 다음, 모든 요청이 예정된 후 모든 요청을 삭제하기 위해 POP 명령을 보냈다는 것입니다. 사용자가 스케줄링을 수행하는 데 15 분 이상 걸렸다면 팝 연결이 시간이 초과되어 앱이 복구 할 수 없었기 때문에 대신 죽었습니다. 그러면 스케줄링을 반복해야했기 때문에 아마도 충분히 오래 걸릴 것입니다. 다시 시간을 보내십시오 ...)

나는 다음의 조합을 생각합니다.

1) 용량의 임계 값 ->이 소프트웨어를 실행하는 데 필요한 기계 및이 숫자가 변경 될 수있는시기를 결정하는 데 사용되는 메트릭 (예 : 2 ~ 3 개의 데이터베이스 서버 또는 10 ~ 15 개의 웹 서버). 하드웨어는 얼마나 쇠고기가되어야하며 한 부분은 다른 부분보다 더 중요합니다. 예 : CPU는 RAM보다 중요합니다. 하드 드라이브 구성 및 공간은 어떻습니까?

2) 요리 책 스타일 문제 해결 -> 어떤 문제가 발생하면, 얼마나 쉽게 코드, 데이터 또는 네트워크 오류로 분류 할 수 있습니까?

3) 환경 다이어그램 ->이 소프트웨어의 개발자, 테스트 및 생산 인스턴스는 어떻게 생겼습니까? 지금 당장 실행중인 다른 환경이 있습니까?

4) 유지 보수 -> 보고서로 구문 분석 할 로그 파일이 있습니까?

5) 보안 -> 시스템에 어떤 수준의 권한을 가진 사람을 간략하게 설명하기위한 보안 정책이 생성되고 관리 될 계정이 있습니까?

그것들은 내 마음에 오는 주요 사람들 일 것입니다.

시스템 관리자는 일반적으로 다음을 원합니다.

  • 시스템 작동에 대한 투명성. 따라서 시스템 설정과 시스템 문제의 이력뿐만 아니라 시스템이 올바르게 처리 한 내용 목록을 보여주는 일종의 GUI.
  • 문제에 대한 명확한 상황에 감지 된 에스컬레이션 경로. 이것은 각 문제 유형에 고정에 대한 메모가 있으며 문제를 신속하게 해결할 수없고 에스컬레이션이 필요하다면 연락 할 수있는 사람 또는 팀이 있다는 것을 의미합니다.
  • 적극적으로 행동하기 위해 최종 사용자가 그에게 알리기 전에 최종 사용자에게 시스템 문제에 대해 알릴 수 있습니다. 따라서 가능한 시스템 문제에 대한 즉각적인 경고가 가능합니다.
  • 경고에 의해 범람하지 마십시오. 따라서 경고가 도착하면 같은 문제에 대한 경고가 더 이상 없습니다. 시스템이 다시 작동 할 때 또 다른 메시지.
  • 문제에 대한 심층 조사를 위해 이벤트 로그 (Windows)와 같은 세부 로깅.

시스템은 단지 아이들에게 집으로 돌아갈 수 있도록 작동합니다.

내 홈 관리자 경험이 지나가는 것이라면 소프트웨어와 함께 포장 된 잘 문서화 된 종속성.

글쎄, 전쟁 시간 이야기보다 더 많은 공포 : 명백한 이유가없는 응용 프로그램을 관리자 사용자 계정에 따라 요구해야합니다.

응용 프로그램에서 가지고있는 것이 좋을 것이라고 생각합니다.

  • 의미있는 명령 줄 인수
  • 일종의 스크립팅 기능 (적절한 경우)
  • 장기 실행 작업에 대한 모든 종류의 진행 지표
  • 오류 로깅
  • 일관된 UI

쉬운 패키지 유지 보수!

소프트웨어를 설치하고 업그레이드하는 것은 간단해야하며, 이는 종속성에도 적용됩니다. 의존성과 하위 의존성이 많고 각 운영 체제의 패키지 관리 방법론의 뉘앙스를 마스터하려는 경향이 없다면, 거대한 타르볼에 묶인 모든 필수 종속성이있는 패키지 버전을 제공하는 것이 좋을 것입니다. . 스크립트를 실행하여 모든 것을/usr/local/yourproject로 chuck하고 시작/종료/재시작 스크립트가 어디에 있는지 알려줍니다.

모든 프로젝트에는 시스템 아키텍처와 함께 '용량 계획'이 있습니다. 시스템 관리자는 용량 계획 프로세스와 시스템 아키텍처의 최종 검토에 참여해야합니다. 이를 통해 시스템을 더 잘 이해하고 배포 및 지원을 준비하는 데 도움이됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top