it-swarm-ru.tech

Какие вещи сисадмина должен знать каждый программист?

Как программист, мы склонны принимать сисадминов как должное. Несколько раз, когда я был без хорошего системного администратора, я действительно ценил то, что вы, ребята, делаете. Когда мы отправляемся в среду, в которой нет сисадмина, какие слова мудрости вы можете нам предложить?

96
Nathan DeWitt

Я бы начал с:

  1. Всегда есть какая-то система резервного копирования. Даже лучше, если у него есть история.
  2. Рассмотрим отдельные точки отказа и как с ними справиться, если они потерпят неудачу.
  3. В зависимости от количества задействованных компьютеров, поиск какого-либо способа создания и создания стандартного образа на разных компьютерах облегчит жизнь всем - никакое "это не работает на моем", потому что у них есть такая и такая программа, которая обычно не устанавливается.
  4. Документируйте все, хотя бы потому, что вы будете забыли, как что-то настраивали.
  5. Будьте в курсе обновлений безопасности.
70
Chealion

<вставьте большой отказ от ответственности здесь>

Некоторые из них были сказаны ранее, но стоит повторить.

Документация:

  • Документ все. Если у вас его нет, установите вики-версию под радаром, но обязательно сделайте резервную копию. Начните со сбора фактов, и однажды образуется большая картина.

  • Создавайте диаграммы для каждого логического блока и обновляйте их. Я не мог сосчитать, сколько раз точная карта сети или кластерная диаграмма спасли меня.

  • Сохраняйте журналы сборки для каждой системы, даже если это просто копирование и вставка команд для сборки.

  • При сборке вашей системы установите и настройте свои приложения, протестируйте их и проведите сравнительный анализ. Теперь протрите диски. Шутки в сторону. 'dd' - первый мегабайт на передней панели дисков, иначе он не сможет загрузиться. Время идет: докажите, что ваша документация может восстановить ее с нуля (или, что еще лучше, докажите, что ваш коллега может сделать это только с вашей документацией). Это составит половину вашего плана аварийного восстановления.

  • Теперь у вас есть первая половина вашего плана аварийного восстановления, запишите остальные; как вернуть состояние вашего приложения (восстановить файлы с ленты, перезагрузить базы данных из дампов), сведения о поставщике/поддержке, требования к сети, как и где получить замену оборудования - все, что вы можете придумать, поможет восстановить вашу систему.

Автоматизация:

  • Автоматизируйте столько, сколько сможете. Если вам нужно что-то сделать три раза, убедитесь, что вторая часть потрачена на разработку вашей автоматизации, а третья полностью автоматизирована. Если вы не можете автоматизировать это, запишите это. Есть комплекты автоматизации - посмотрите, сможете ли вы заставить их работать на вас.

Мониторинг:

  • Прикладная аппаратура из чистого золота. Возможность наблюдать за транзакциями, проходящими через систему, значительно упрощает отладку и устранение неполадок.

  • Создавайте сквозные тесты, которые доказывают не только то, что приложение живое, но и действительно выполняет то, что должно. Очки ваши, если их можно подключить к системе мониторинга для целей оповещения. Это служит двойной обязанности; Помимо проверки работоспособности приложения, оно значительно упрощает модернизацию системы (мониторинг системных отчетов зеленый, обновление сработало, время идти домой).

  • Оценивайте, отслеживайте и собирайте метрики для всего, что для этого необходимо. Тесты показывают, когда ожидать, что что-то испустит волшебный дым. Мониторинг говорит вам, когда он имеет. Метрики и статистика облегчают получение нового комплекта (со свежим волшебным дымом) через управление.

  • Если у вас нет системы мониторинга, внедрите ее. Бонусные баллы, если вы действительно включите в него вышеописанные сквозные тесты.

Безопасность:

  • "chmod 777" (он же предоставляет все права доступа) никогда не является решением проблемы.

  • Подпишитесь на принцип "наименьшего бита"; если он не установлен, скопирован или иным образом находится на диске, он не может быть скомпрометирован. Установка "кухонной раковины" ОС и программного обеспечения может облегчить жизнь на этапе сборки, но в конечном итоге вы заплатите за это в будущем.

  • Знайте, для чего предназначен каждый открытый порт на сервере. Регулярно проверяйте их, чтобы убедиться в отсутствии новых.

  • Не пытайтесь очистить скомпрометированный сервер; это должно быть восстановлено с нуля. Перестройте на резервный сервер со свежескачанными носителями, восстановив только данные из резервных копий (так как двоичные файлы могут быть скомпрометированы), или клонируйте скомпрометированный хост куда-нибудь изолированным для анализа, чтобы вы могли восстановить на том же наборе. Вокруг этого существует целый правовой кошмар, так что ошибайтесь в сторону сохранения на тот случай, если вам нужно искать законные пути. (Примечание: IANAL).

Оборудование:

  • Никогда не предполагайте, что что-то будет делать то, что написано на коробке. Докажите, что он делает то, что вам нужно, на случай, если это не так. Вы обнаружите, что говорите "это почти работает" чаще, чем вы ожидаете.

  • Не экономьте на удаленном управлении оборудованием. Последовательные консоли и управление освещением следует считать обязательными. Бонусные баллы за дистанционно управляемые удлинители питания в те моменты, когда у вас нет выбора.

(Кроме того, есть два способа решения проблемы в 3 часа ночи, один из которых заключается в том, чтобы быть тёплым, работать на ноутбуке через VPN в вашей пижаме, другой - в толстой куртке и подъезжать к центру обработки данных/офису. Я знаю, какой предпочитают.)

Управление проектом:

  • Вовлеките людей, которые будут поддерживать систему с первого дня жизненного цикла проекта. Время выполнения заказов и время на подготовку могут и будут удивлять, и нет никаких сомнений в том, что они будут (должны?) Иметь стандарты или требования, которые станут зависимостями проекта.

  • Документация является частью проекта. У вас никогда не будет времени, чтобы написать все это после того, как проект будет закрыт, и система перейдет на техническое обслуживание, поэтому убедитесь, что это включено в график в начале работы.

  • Внедрите запланированное устаревание в проект с первого дня и начните цикл обновления за шесть месяцев до дня выключения, указанного вами в проектной документации.

Серверы имеют определенный срок службы, когда они пригодны для использования в производстве. Конец этого срока службы обычно определяется как каждый раз, когда поставщик начинает взимать больше при ежегодном обслуживании, чем это будет стоить обновить комплект, или около трех лет, в зависимости от того, что меньше. По истечении этого времени они отлично подходят для сред разработки/тестирования, но вы не должны полагаться на них для ведения бизнеса. Пересмотр среды за 2 1/2 года дает вам достаточно времени, чтобы перепрыгнуть через необходимые управленческие и финансовые операции для заказа нового комплекта и осуществить плавную миграцию, прежде чем отправлять старый комплект крупному поставщику в небе.

Разработка:

  • Убедитесь, что ваши разработки и системы постановки напоминают производство. ВМ или другие методы виртуализации (зоны, LDOM, vservers) упрощают создание клонов "в реальном мире, в каждом смысле, но производительности".

Резервные копии

  • Данные, которые вы не сохраняете, - это данные, которые вам не нужны. Это неизменный закон. Убедитесь, что ваша реальность соответствует этому.

  • Резервные копии сложнее, чем они выглядят; некоторые файлы будут открыты или заблокированы, в то время как другие должны быть приостановлены, чтобы иметь хоть какую-то надежду на восстановление, и все эти проблемы необходимо решить. В некоторых пакетах резервного копирования есть агенты или другие методы для работы с открытыми/заблокированными файлами, в других - нет. Сброс баз данных на диск и их резервное копирование считается одной из форм "успокоения", но это не единственный метод.

  • Резервные копии бесполезны, если они не проверены. Каждые несколько месяцев вынимайте случайную ленту из архивов, убедитесь, что на ней действительно есть данные, и что данные согласованы.

И, самое главное...

Выберите режимы отказа, или Мерфи будет ... и Мерфи не работает по вашему расписанию.

Проектируйте для отказа, документируйте спроектированные слабые места каждой системы, что вызывает их и как восстановить. Это будет иметь значение, когда что-то пойдет не так.

44
Greg Work

Не думай, что это легко. Я знаю многих программистов, которые думают, что только потому, что они могут настроить IIS или Apache на своем компьютере разработчика, чтобы они могли запускать веб-ферму. Понимать, что включает в себя работа, и проводить исследования и планирование, не Просто подумайте, что работа системного администратора - это простая вещь, которую вы можете сделать за 10 минут, чтобы развернуть ваше приложение.

43
Sam Cogan
  • Поймите, что, к лучшему или к худшему, многие серверы и/или сетевое оборудование, как правило, очень похожи на детей из второй семьи. Это их дети. Они ухаживают за ними, помогают им, когда они болеют, и бдительно следят за их проблемами. Это не должно быть таким, но через много лет это часто бывает . Помните об этом, когда будете сообщать им о своих опасениях по поводу того, что оборудование не работает должным образом или не стоит ожидать. И если вы получите ответ, которого вы не понимаете, попробуйте отфильтровать его через это мировоззрение.
  • Будьте в хороших рабочих условиях. Звучит сырно, но на вес золота. Когда-нибудь вам понадобится особая услуга. И однажды этот системный администратор будет рад сделать все возможное, чтобы сделать жизнь немного проще для вас, только в этот раз.
  • Эти рабочие отношения идут в обе стороны. Если системный администратор очень занят, и вы могли бы немного облегчить жизнь, написав небольшой скрипт или программу, сделайте это! Они оценят это больше, чем вы знаете.
  • Будь очень ясным. "Это отстой" не так ясно, как "наличие прерывистого сетевого подключения немного раздражает, есть ли шанс, что вы можете посмотреть на это?"
  • Если вы думаете, что ваше приложение будет масштабироваться, спросите администратора прежде , предполагая , что оно будет. Они могут "увидеть" что-то, чего вы не знаете, или узнать что-то об ограничениях производительности оборудования, на котором вы собираетесь развернуть.
  • Если ваше приложение нуждается в настройке, но оно не является проблемой кода, спросите, как работают серверы. Сисадмины заботятся о своих машинах с любовью и не довольны, когда они "болеют" или "плохо себя ведут". Хорошая просьба перевернет больную машину (или отремонтирует/заменит).
  • (как уже упоминалось в другом месте) задокументируйте используемые вами настройки и почему вы их используете. Просто "установить флажок X" или "раскомментировать строку конфигурации файла Y" не поможет. Вы можете установить опцию, которая удаляет все ваши данные при следующей перезагрузке для всего, что вы знаете.
  • Если у вас нет времени документировать настройки на бумаге, попробуйте документировать их в системе, если это возможно. Для конфигурационных файлов это должно быть практически стандартной практикой - каждое изменение параметра должно быть помечено датами, с инициалами, ожидаемым эффектом этого параметра и причиной почему оно было изменено (см. предыдущий пункт). Эта небольшая привычка спасла мой бекон не раз во время хруста. "Почему мы это сделали?" "Потому что мы предписали политику X, а параметр Y дает нам поведение, необходимое для политики X".
  • Пиво. Или кола. Или даже Вода. Напитки всегда приветствуются. Быть сисадмином - это жаждущая работа.
27
Avery Payne

Безопасность не запоздалая мысль. В то время как взломанное приложение может заставить программиста выглядеть некомпетентным, это (по крайней мере) потерянные выходные, потраченные на проверку, очистку и/или восстановление из резервных копий системного администратора.

В этом отношении, не рассматривайте резервные копии как контроль версий. Они предназначены для аварийного восстановления и не предназначены для восстановления вашего кода, потому что вы забыли, что изменили.

И перестаньте слепо обвинять Обновления Windows в нарушении вашего кода. Мне все равно, что это сработало раньше, скажите мне, почему это не работает сейчас - тогда мы сможем увидеть, чья это вина.

23
Mark Brackett

Как отлаживать проблемы с сетью и наблюдать за тем, как ваша программа работает с помощью инструментов sysadmin. Как программист, который начал заниматься системным администрированием, я поражен тем, насколько бессильными становятся многие программисты, когда работа в сети "просто прекращается".

  • Wireshark, чтобы посмотреть, как ваш код работает в режиме черного ящика, пакет за пакетом
  • Инструменты для прямого подключения к сетевым сервисам:
    • Telnet, netcat или socat для простых соединений через TCP или UDP)
    • OpenSSL за то же самое с шифрованием (подсказка: попробуйте openssl s_client -connect target-Host:port иногда), для ручного подключения к сетевым сервисам
  • Dig (в пакете BIND 9) для разрешения отладки имени
  • Возможность определить, какая часть сетевого стека вышла из строя, исходя из времени и других характеристик неисправного соединения
  • Возможно HTTPFox и/или Firebug
17
jhs

Знать, как решать проблемы.

Это очень легко преодолеть (например, ваша сеть теряет связь с базой данных). Это может быть ошибка сети, но у вас должны быть журналы приложений с ошибками, которые, используя Google или SO, могут выявить проблему в конфигурации приложения.

Каждый любит обвинять аппаратное обеспечение, ОС или сеть, поэтому, если вы будете немного больше проявлять должную осмотрительность, вы сделаете сисадмина счастливым человеком. Потому что, если не что иное, вы можете указать им конкретное направление относительно того, что может быть не так (в отличие от того, чтобы сказать "ваша сеть отстой" или что-то такое же полезное).

14
Milner

Документируйте все, что можете. Не могу сказать, сколько раз последний системный администратор думал, что было бы мило не документировать что-либо для "обеспечения безопасности работы" или кто-то просто хотел войти и выйти. Как программист должен оставлять хорошие комментарии, так и системные администраторы должны документировать. Схема топологии тоже была бы хороша.

8
Terry

План B.

Всегда имейте в виду план аварийного восстановления при проектировании и разработке решения. Распознавать отдельные точки отказа, которые могут привести к отключению.

7
spoulson

Документация: не нужно сходить с ума, но как работает приложение, диаграмма, показывающая, как подходят биты, и способы тестирования каждого компонента, когда все идет не так. Пример данных и вывод хороший.

Требования: на какие модули он опирается? Версии? ОПЕРАЦИОННЫЕ СИСТЕМЫ?

Мониторинг: в идеале разработчики должны включать мониторинг информации и тесты с приложением.

Кстати, об упаковке, УПАКОВКЕ! Нет ничего хуже, чем "развертывание", которое означает, что нужно проверить новую версию файла из VCS и скопировать ее на несколько серверов. Слишком часто программисты не ценят сложность развертывания программного обеспечения: есть причины, почему версионное, упакованное программное обеспечение составляет основу большинства операционных систем.

Если бы разработчик пришел ко мне с RPM, который был установлен впервые с краткой, исчерпывающей документацией и некоторыми тестами Nagios, они были бы моим новым лучшим другом.

6
markdrayton

Я удивлен, что ни один из 17 ответов, приведенных здесь, пока не содержит ничего о том, как обеспечить работу вашего приложения при входе в систему как обычного пользователя.

Помимо процесса установки, приложение должно работать нормально при входе в систему со стандартной учетной записью пользователя.

6
Bryan
  • поговорите со своим администратором официально и неофициально о том, что вы делаете. Как правило, они будут заинтересованы и могут выразить возможные последствия на производстве на раннем этапе. Вы не должны соглашаться, но это помогает определить проблемные места.
  • Нет, вы не можете иметь весь сервер для себя ... Если вам нужно, это политическое решение, независимо от того, насколько оно технически обосновано. Если вы хотите работать в политике, идти вперед.
  • Производственное оборудование часто выглядит иначе, чем ваш сервер разработки, и даже внутри ферм спецификации на машины отличаются.
  • Узнайте, как настроено производство, потому что вы, вероятно, не сможете воспроизвести его на своем рабочем столе, так как это поможет вам сделать неверные предположения.
  • Тот факт, что вы можете кэшировать данные в памяти, не означает, что вам следует сначала подождать узкого места (в модульном тестировании или тестировании производительности перед началом производства)
  • если вы помещаете данные в базу данных, подумайте о том, как разбить данные на данные только для чтения (которые можно масштабировать по горизонтали) и данные для чтения и записи (которые обычно масштабируются только по вертикали).
  • если вы помещаете данные в базу данных, должна ли быть действительно СУБД? Существуют и другие системы пар ключ-значение, которые лучше масштабируются (netcache).
  • не думайте AJAX - это универсальное решение, оно выглядит круто, но оно ограничивает возможности мониторинга и автоматизации. Я не говорю, что не используйте его, просто подумайте дважды.
4
ericslaw

ОК, это немного разглагольствует, но:

а) При кодировании предположите, что базовая инфраструктура может выйти из строя и не приходит от счастливой счастливой всегда на суше. Или гугл.

б) У нас, вероятно, нет ресурсов для реализации чего-либо вроде инфраструктуры, о которой вы читали, так что будьте спокойны, когда дела пойдут плохо. Вероятно, мы знаем, что нужно сделать, но по какой-то причине это еще не произошло. Мы ваши партнеры!

c) Как сказал выше jhs, было бы очень полезно, если бы вы были знакомы с инструментами для устранения неполадок инфраструктуры, такими как ping, traceroute (или объединение обоих - mtr), Dig и т. д. Огромные бонусные баллы за то, что вы даже знаете о Wireshark.

d) Если вы программируете компьютер, вы действительно должны знать, как он подключается к сети, а также основам, таким как возможность анализировать выходные данные ipconfig/all или ifconfig. Вы должны быть в состоянии установить ваше интернет-соединение с минимальной помощью.

В противном случае я думаю, что Эйвери в значительной степени прибил это Разработчики, которые делают немного сисадмина, на вес золота! Но в равной степени, системные администраторы, которые понимают, как разработчики идут о вещах (включая управление версиями и т.д.), Очень важны в наше время.

Кажется, в данный момент это происходит, я заметил больше дискуссий об отношениях dev/ops в блогах.

Сохранение Твиттера в Твиттере

Разделы и Война

сначала тест в операциях

4
Cawflands

Резервное копирование Резервное копирование .... Проверьте резервную копию .... Всегда будьте готовы к откату

4
trent

Это может относиться только к начинающим программистам, но я имею дело с некоторыми вещами в каждом проекте с некоторыми программистами.

  1. "Это работает на моей машине" не является действительным утверждением. Программист несет ответственность за создание программы установки для использования на сервере или, по крайней мере, документирование каждого соединения и DLL и надстройки, которые потребуются на сервере.

  2. (Я слышал это несколько раз, поэтому, пожалуйста, не смейтесь) Я запускаю exe на сервере со своей машины, и он работает. Но когда я запускаю его на сервере (Citrix, Terminal Server и т.д.), Он не работает. Пожалуйста, поймите, dll, ocx и все остальное, что требуется вашей программе, где и как они зарегистрированы, и как ваша программа использует их.

Это может показаться простым, но я занимаюсь этим постоянно.

Брайан

4
Brian

Что ни одна группа или функция не "лучше", чем другая, и что ни одна из них не требует "большего мозга", чем друг друга. Я видел, как обе стороны проявляют примадонность в компании другой - вы все пытаетесь достичь одних и тех же целей - сосредоточьтесь на этих сходствах, а не на том, что вы используете разные инструменты.

3
Chopper3

Архитектор инфраструктуры, ставший программистом, возможно, захочет откатить эту транзакцию в будущем :)

  1. Поговорите друг с другом, рано и часто. Просмотрите проекты с парнями, которые будут управлять инфраструктурой, на которой будет развернуто ваше приложение (если вы знаете, кто это будет).
  2. Нулевая потеря данных возможна, но ответственность за это несут разработчики и системные администраторы. Снова, общение друг с другом может помочь здесь.
  3. Сотрудники вашей инфраструктуры должны были участвовать в определении нефункциональных требований.
  4. Организовать пиво (когда работа сделана) и пиццу (пока мы работаем). Каким-то образом присутствие такой еды влияет на нашу способность заставить наши милые маленькие 32 процессорные коробки делать то, что вы от них хотите :)
2
Vincent De Baere

Как кто-то, кто был системным администратором для разработчиков и сам разработчик, совет, данный здесь, не только золотой, но и должен быть частью документации по найму новых разработчиков для компаний во всем мире.

Что-то, что я не видел (пока) объяснил, так это то, что разработчики действительно должны знать продукты, которые они будут использовать для создания программ, за которые им платят. Количество случаев, когда мне приходилось объяснять и настраивать серверы Apache, установки Eclipse и Visual Studio, а также базы данных на компьютерах разработчиков, вызывает некоторое беспокойство.

2
canadiancreed