Какие штуки приходится писать админу? Perl, python, bash, sed/awk

Это нужно для автоматизации рутины.

Пример: надо каждый день в определенное время ходить на несколько серверов, делать резервные копии базы данных, паковать эти копии в архив, копировать этот архив по сети, проверить работоспособность резервных копий и т.д. и т.п.

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

СРК практически вручную? И часто такое бывает сейчас в более-менее крупных компаниях? И как проверяется работоспособность копии? А если она изменена каким-нибудь криптором?

Понятно, что скрипты это автоматизация. Но конкретно что бывает необходимо автоматизировать, по опыту?

Когда приходится делать что-то админское, то я просто фильтрую по разному вывод разных комманд через grep/awk/head/sort/uniq. Потом иногда скармливаю в xargs. Еще иногда вместо того чтобы знать какой-то магический ключ в команде для фильтрования результатов мне реально проще порезать регексами весь вывод

СРК практически вручную? И часто такое бывает сейчас в более-менее крупных компаниях?

А хз, это выдуманный пример.

И как проверяется работоспособность копии?

Например, накатывается на тестовый сервер.

Да в основном всякие скрипты для деплоя, бекапов, конфигурирования свежих серверов, иногда для сборки пакетов.

Ты что, кроном работаешь?) Это всё он должен делать

По сабжу: чем меньше скриптов приходится писать, тем лучше. В 99% случаев хватает bash/однострочников на perl. Скрипты нужны для cron и для первичной настройки(через SCM естественно)

в основном простенькие баш-скрипты.
но приходилось и парсер логов писать, который с бд работает.
надо питон выучить =(

Ты что, кроном работаешь?)

Нет)

Это всё он должен делать

Понятное дело, но чтобы он начал что-то делать, ему надо рассказать как именно он это должен делать.

Опыта у меня немного, но использую shell в основном чтобы быстро спарсить лог или конфиг какой-то.

Раньше много всего писал на питоне и на баше. ПОтом пришло понимание того, что чем меньше велосипедов - тем лучше. Стараюсь писать скриптов по минимуму. Сейчас есть один скрипт для бекапа через rsync на баше, но это уже скорее legacy. И немного всякой автоматизации на python+saltstack.

тут всё зависит от команды. Например я могу написать забористый sed-скрипт, но так не делаю, просто потому, что мало кто имеет такую практику. Потому я использую bash, его понимает любой квалифицированный администратор.

Впрочем, в некоторых командах хорошим тоном является перловка, а питон считается моветоном(обратное теоретически возможно, но я не встречал таких случаев).

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

это конечно так.

Достаточно ли просто понимать написанный код и уметь его поправить?

Смотря что у тебя за должность и обязанности будут. Вообще bash в системном администрировании это скорее конвейер - «запусти такую программу, потом если она вернула такую строку запусти другую программу, а если нет - третью». Python использую если нужно взять какие-то данные, обработать и красиво показать - всякие таблички рисую и т.д. Perl не осилил, да и с учетом того что мои скрипты периодически уходят другим коллегам для меня очень важна читаемость кода.

Опять же важно с чем ты работаешь - админя какие-нибудь Weblogic'и python очень поможет, потому что он используется в тулзе управления сервером, а если у тебя что-то уровня хомпейджа на php, то тут и bash хватит.

В общем, знания этих языков лишними не будут, но и при необходимости в том же bash\python поверхностно разобраться можно довольно быстро.

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

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

Ну, у меня тут корыстный умысел. Скрипт потом можно дать сотруднику, для которого, собственно, и нужно выполнить эту работу, даже если он в ИТ не силён, тем самым делегировав ему часть своих обязанностей. И ему хорошо, и мне хорошо - время не тратим впустую :)

по сабжу чаще скрипты для мониторинга хостов/пользователей/выполняемых задач, изредка конвертеры для конфигов программ (облегчить миграцию с одного софта на другой, бэкап с последующими действиями, парсинг с обработкой полученных данных (сложить в БД, переслать и т.д.) из кучи информационного шума, всякие информеры с сайтов (новости, новости обновления программ и т.д), реже боты всякие, или составление отчётов.

P.S. я больше локалхост-админ и яумамыхакир, так что хз что приходится писать реальным админам.

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

Авторазвёртывание виртуалок, автодеплой туда же, мониторинг, сбор статистики, анализ статистики.

Инструменты:
Прототипирование на баше
Продакшн на питоне

СРК практически вручную?

Не система бекапа, а скрипты для системы бекапа. Есть одна единая система бекапа, но никто не говорит что она умеет с полпинка бекапить вообще всё что уже написали и напишут. В общем случае СРК умеет бекапить ФС и несколько типов самых распространённых БД. Скрипты для остального будешь искать, устанавливать и допиливать сам. Примеры с потолка - ldap, derby

красноглазый пердолинг в консоли, всё делаю через гуй.

гуй - преимущество над консолью? :-D

Ещё какое. Для нормальных людей-то, а не студентов-задротов.

Говорит лишь о том, что ты либо эникейщик, либо менеджер либо вообще посторонний. Windows админы используют powershell или python.

Ещё какое

в каких задачах это преимущество можно увидеть?

Не корми тролля, он и так толстый ;)

Часто вижу в описаниях вакансий на linux-админа требования писать/читать именно на том, что в сабже.

В 99% случаев эти описания пишет HR, который в вопросе разбирается чуть менее чем никак и копирует все слова, которые нагуглил(а).

ЯП нужен в первую очередь тебе, потому что значительную часть задач занимает действия, которые можно автоматизировать. Никто не говорит о том, чтобы с воплем «Ура» и под дробь барабана кидаться писать что-то с нуля. Для большинства задач есть специализиронное ПО, и в 99% случаев это ПО уже включено в репозитории твоего дистрибутива.

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

Достаточно ли просто понимать написанный код и уметь его поправить?

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

Ещё раз, как правило, от кандидата на должность не требуется знать все перечисленные языки. Достаточно знать один язык плюс быть готовым к работе с новым языком, если вся остальная команда используют именно его.

Вот как донести это до HR - вопрос на миллион...

Например я могу написать забористый sed-скрипт, но так не делаю, просто потому, что мало кто имеет такую практику.

Еще бы потом не забыть что написал-то на sed.

Хехе, про «достаточно просто» имею в виду не сложность понимания кода, а «достаточно ли знать только это». Но в целом ясно-понятно. Особенно ок про передачу инфы из СРК в мониторинг, надо будет потренироваться на кошках.

А какие именно задачи на практике вам приходится реализовывать? примеры?

• Приведение серверов к определённым требованиям ( внутренний регламент, pci dss, vmware hardening guide ). Как правило, через систему централизованного управления, в которую в простейшем случае забивался список требований, если СЦУ умела эти требования выполнять сама, либо команда или скрипт.

  Для vsphere - скрипт на powershell или perl

• скрипты для отправки информации в систему мониторинга из puppet, vsphere, avamar, ossec, pacemaker, klms, san массивов, nginx. Как heath, так и метрик производительности.
• вспомогательные скрипты для бекапа тех БД, с которыми из коробки не умеет работать система бекапа.

• разбор дампов, собранных wireshark. На входе дамп, на выходе - интересующая информация, например список коннектов и их длительность.
• разбор логов. На входе лог, на выходе - та информация, которая в данный момент интересует
• построение графов для визуализации лога или конфига

bash - минимум, который нужно знать. Не на уровне гуру. Необходимый минимум - циклы, подстановка переменных.

perl/python/ruby/что_там_ещё - следующий уровень. Позволят делать более сложные вещи

Регулярные выражения можно вынести отдельным пунктом. Крайне желательно уметь с ними работать. И не важно, sed, grep, awk или perl

в каких задачах это преимущество можно увидеть?

лайкнуть фотку

Еще бы потом не забыть что написал-то на sed.

я в начале пишу

#/bin/sed -rf

Ребят, а сейчас ещё кто-то занимается этим..? Я думал, что виртуализация уже давно всех победила, и сейчас поднимают сразу с копии весь узел..? Нет?! Я думал, что только я один такой унылый...

А виртуалки у тебя как снапшотятся\разворачиваются, через libastral? =)

Да я то тёмный... Очень тёмный... У народа же вроде как через libastral уже давно. Ведь MS, уже запилила давно репликацию для Hyper-V, для Esxi есть Veam, и ещё куча всего. Для амазона есть амазон... Чего я не учёл..?

Да я сам темный)) Но в любом случае что-то помимо стандартного поведения придется делать руками.

Я тёмный, но я вижу, что всё это в прошлом... В очень прошлом. :( Будущее за программистами. Админы - не нужны. :) Хотя я всё ещё нужен, как это не странно... :)

Есть программисты, которые непосредственно пишут код; и есть админы, которые поддерживают все то, в чем этот код крутится - от сетей до серверов приложений.

для Esxi есть Veam, и ещё куча всего

Есть. Но всё это не для БД

Будущее за программистами. Админы - не нужны.

Это как «будущее за интернетом вещей, электрики и сантехники не нужны». Ниша сократится, но вряд ли исчезнет.

Да ну..? Сейчас теже Windows поддерживают VSS + MSSQL. Всё уже сделано, и продумано. :)

Возможно. Но в таком случае кроме БД в бекап попадёт ОСь, что в случае windows не мало

Я думаю ниша будет, исчезающе мала эта... :)

Посмотрим ;)

Да перестань... У меня базы по 200 гиг, сраная винда со своими 20гб, это ни об чём. В любом ентерпрайзе так. +Зато ты можешь очень быстро поднять бекап в консистентном его состоянии, и посмотреть как оно там всё живёт, тот-же Veam - позволяет клонировать настройки сети... - То есть если у тебя одна машина зависит от другой - не вопрос, две поднимишь, да хоть десять, и посмотришь, что твои бекапы - ОК! А вот скриптами, такое делать умрёшь... - Оно будет конечно работать, но падать громко тоже будет. :)

Да перестань... У меня базы по 200 гиг, сраная винда со своими 20гб, это ни об чём.

У нас базы среднего размера живут на железных серверах или lpar'ах. На виртуалках базы до 50 Гб.

В любом ентерпрайзе так.

Умножаем количество баз на 20 гигабайт и идём просить деньги ещё на несколько полок расширения.

Зато ты можешь очень быстро поднять бекап в консистентном его состоянии

Для этого есть стендбай

Что за стендбай? Тебе надо к примеру поднять app + db, и всё это в связке с другими app. Какой стендбай... :) К примеру ERP без CRM из себя мало что представляет...

А почему виртуализации не доверяете большие базы? Какая виртуализация? Я вот с kvm балуюсь, пока в целом - ничего вроде...

Тебе надо к примеру поднять app + db, и всё это в связке с другими app

В предыдущем комментарии речь шла о том, чтобы в случае проблем быстро поднять БД в консистентном состоянии. Для этого хорошо бы иметь стендбай или даже кластер, а не восстанавливать всю ВМ из бекапа

А почему виртуализации не доверяете большие базы?

Доверяем, но на power'ах они быстрее работают

Какая виртуализация?

vsphere

Ага, ну особо то ведь не нужно там скриптовать то..? Не? У меня очень маленькие нагрузки, но крайне много сервисов... Я kvm пока выбрал, десятки виртуалок бегают...