Всем привет.
Вопрос следующий. В текущий реалиях, админу все больше и больше приходится писать скрипты на чем то отличном от bash/awk, и реализовывать чуть более сложную автоматизацию чем раньше.
В ход идут у кого то perl, у кого то python у кого то еще что то.
Постольку поскольку пишется не так уж и много но все чаще, стал замечать что трачу слишком много времени на написание этих скриптов/демонов. Написание 200 строк кода на питоне, по примитивной задаче (парсинг, агрегация, доставка в несколько стораджей) может занять 4 часа времени, а потом еще пару часов на исправление косяков.
И если делать по 1-2 таких задач в месяц, то прогресса в скорости написания и лаконичности кода почти нет.
Понятно что нужно больше практиковаться, но уделять просто так пару часов в день написанию скриптов не удается.
Как Вы, тренируете себя, и свои навыки в таких условиях ?
Вопрос в первую очередь к системным админинстраторам, и всяким там devops'ам :)
По возможности использовать системы оркестровки, если все-же приспичило писать свой костыль, то только для очень частых задач, ради разовой работы нет смысла (если это не однострочник). Я куски часто используемых кусков и заготовок со своих разных скриптов закидываю в заметки и каждый новый не пишу целиком с нуля а надергиваю из более старых 90% кода, для админа нет задачи писать быстро скрипты, лучше изучать готовые системы решающие задачи, т.к. скрипты придется поддерживать, обновлять и допиливать, часто уже есть готовый инструмент, надо просто его изучить и все задачи по развитию и обновлению уходят на производителя инструмента ну или пилить всем миром опенсорс, но не в одно рыло сотни скриптов - это не админский профиль.
Не пойму чем помогут системы оркестровки когда нужен сбор данных из различных источников, их анализ и сведение для получение некоторой объективной информации о работе сервиса (к примеру). "Пороговый" мониторинг не всегда удобен.
На тему повторного использования кусков кода, абсолютно согласен это ускоряет написание, но я пока максиму 20-30% накидываю из готового.
На счет того что "неадминское это дело", пожалуй с Вами не соглашусь.
> "Пороговый" мониторинг не всегда удобен.
Используйте оперативный мониторинг, с графиками и прочими плюшками, зачем тут свои костыли?
> На счет того что "неадминское это дело", пожалуй с Вами не соглашусь.
Ваше право, скрипты пишут все, но вот если это стает очередным занятием - надо задумываться а не пишем ли велосипед для давно решенной задачи.
Доставка данных, обработка происходящих событий с сложными вариантами оповещений (изменение оповещний не просто от времени а от типа "триггеров", дней недели, частоты срабатывания, и "дестинейшона" оповещения, почта или смс к примеру), требует своих собственных костылей. Но это не что иное как автоматизация каких то действий, и это одна из первостепенных задач администраторов. Если все ездят на уницикле и говорят что им удобно, это не повод не изобретать мне мой собственный велосипед.
ptchol: Все ваши хотелки по мониторингу с ходу решает тот же zabbix прямо вот по всем пунктам, еще и сам новое железо заведет, склад обновит и аналитику покажет, могу для любой из них скринкаст показать :) Не знание готовых инструментов рождает костыли, ну не один вы админ в мире, если вы с чем-то столкнулись, то с большой долей вероятности уже есть либо проверенный инструмент либо готовый костыль.
Сергей Петриков Мы с zabbix'ом дружим уже очень давно, но нет, не всегда решает, по крайней мере 2.2, до 2.4 не дойдут никак руки. То что я привел, стоит воспринимать не как отдельные требования а как комплексный набор условий. Я в курсе про эскалацию событий, и про сложные триггеры которые позволяют выявлять "тренды" по дням, и на основании этого делать оповещения или нет (избавление от срабатываний на регулярных спайках, но вылавление спайков выше обычных) и т д. Но заббикс много чего не умеет, наверняка же Вы радовались (как и я) когда позволили в 2.4 добавить на скрин прототип графика и сделали более человечным action condition ? Когда вам нужно для ряда триггеров, сделать специфичный шаблон оповещения, но при этом избежать дублирования алертов на почте, вам заббикс кажется очень удобным ? У кого то таких задач не стояло и они считали что заббикс подходит для всего.
И при этом, вы пытаетесь мне доказать что нет таких задач для которых еще нет инструмента ? Спорить не буду, хотя мне и кажется это слишком уж оптимистичным вариантом. Но так или иначе это не значит что всем может быть удобно использовать в данной инфраструктуре данный инструмент.
И изначальный вопрос не звучал как "мы пишем собственные костыли, как мне это делать быстрее", вы мне кажется это сами додумали, без обид :)
ptchol: По 2.4 да до этого у меня был свой скрипт (небыло - написал, но это мелочь, а не вся система мониторинга), который генерировал комплексные экраны нужных мне узлов, то что добавили в LLD стало приятным бонусом. В моем кейсе на почту уходят проблемы, только не решенные втечении 30 минут и не подтвержденные, основное оповещение - сирена дежурным инженерам, там дублирование даже плюс, чаще воет - быстрее булками шевелят :) Я заббикс панацеей не называл, но по описанным выше кейсам он справляется прекрасно, у него на данный момент из проблем - слабая карта, ну вот неудобная она и сама генериться не умеет без кучи костылей, хотя можно было бы допилить, отсутствие генерации еженедельной аналитики с отсылкой на почту (хотя есть на форуме плагин), еще лично мне не нравится склад, т.к. нельзя в поиске задать свои поля в шапке а надо подстраиваться под готовые, либо переписывать фронтенд. Скрипты пишут все, но я стараюсь их сознательно писать как можно меньше, у вас никогда не возникало необходимости подправить жирный скрипт написанный 3 года назад и занимающий страниц 20-30 текста, смотрите в него и ничерта уже не понимаете какой баран это писал :) Я к тому, что для админа скорость написания скриптов - не главный показатель качества работы и не его хлеб, ну буду писать 5 часов вместо 2х, ну и хрен с ним, если он облегчит мне задачу, а инструмент выполняющий то же самое я за 30 минут не смог нагуглить и нагитхабить, какой смысл прокачивать этот показатель, если нет цели уйти в программисты?
Сергей Петриков Согласен, скорость скриптописания не сильно важна. Но мне кажется админам в будущем придется чуть больше кодить. Те же модули для puppet, если вы пишете собственных 'providers', требуют написания их на руби. Часто встречается инструментарий на том же гитхабе, который в сыром виде сложно применить, но можно интегрировать добавив некоторую прослойку. Со стороны начальства я не ощущаю недовольства скоростью реализации задач, это скорее требование к себе (недовольство собой если хотите), писать быстрее, проще, красивее, и так чтобы этим можно было делиться.
ptchol: Я думаю в будущем даже программистам приходится кодить меньше, всю работу на себя берут фреймворки, библиотеки, модули и IDE, хотя я не Ванга, тут спорить не стану, кто его знает как повернется. По модулям - да, но это не совсем скрипты, я в puppet не силен, ansible предпочитаю, там скорее не скрипты а продвинутая работа с синтаксисом самой системы, хотя как посмотреть может вы и правы, но 80% (цифра с потолка статистики нет) рецептов я беру готовых и чуть переделываю под себя. Если это вам лично нужно, тогда другой вопрос, как и любое ремесло, чем чаще делаем, тем быстрее руку набиваем, вряд-ли тут будет какая-то неожиданная откровенность. У меня выходит, что пишу скрипты все меньше и меньше, все больше занимаюсь стратегическими а не тактическими задачами, за них оплата лучше, если брать именно администратора.
Так то если задача 1-2 раза в месяц, смысла заморачиваться нет. Также как и выполнять задачи ради задач.
Если хочется именно опыта - переписывайте старые скрипты, новые пишите с использованием интересующей технологии.
Добавляйте доп. функционал в текущие инфраструктурные системы, мониторинги всякие, аналитика красивая и т.д.
Остановитесь на одном скриптовом языке (который используется в команде/хочется изучить и тд, любой критерий подойдет; я бы сказал, что лучший выбор python3), изучайте его standart library, гуглите решение для своих задач, находите готовые модули/паттерны; для многих языков уже много готовых батареек. А дальше дело просто в практике.
Привет кэп ! Именно про это я и написал, что есть некий "переходный" этап, когда задач становится больше, но еще недостаточно чтобы скилл начал прокачиваться.
ptchol: ну и кстати, написать парсинг/агрегацию + свистелку за полдня, чтобы потом это работало и ты забыл о проблеме, мне кажеся, совсем не плохо и не медленно
Если сисадминить не linux а Windows то вопрос решается легко, нужно писать на более контролируемых языках со строгой типизацией, к примеру написание любого из вышеперечисленного на C# можно легко выполнить за полчаса и на отладку уйдет от 0 до 10 минут, у меня с опытом чаще первый случай.
Средний
