Nginx к слову написан как раз админом, но да не будем.
Как человек, побывавший со всех сторон сервис деска, могу сказать, что регламенты придуманы не просто так. Да, они могут быть устаревшими, глупыми (и потому надо пересматривать), но писать в заявке всю необходимую информацию нужно хотя бы потому, что сервисный инженер не может залезть в голову писавшему и вынуть все.
На одной работе заявку написанную не по регламенту просто закрывали, со ссылкой на регламент, во второй раз — закрывали и пересылали руководителю с пометкой «сотрудник не читает регламенты», в третий раз — пересылали руководителю руководителя. Четвертого раза как-то не вспомню :)
Естественно, за перегибы могли вздрючить и сервисника. Нефиг докапываться до мелочей, думать-то все равно надо головой, а не регламентом.
Если вы интересуетесь инфраструктурой и не делаете так — честь вам и хвала, но не все же разработчики такие?
Внезапно, но нет.
IDE — это именно текстовый редактор с плагинами. Автокомплит, подсказки, и все остальное — плагины. Остальное — умение использовать sed/grep/awk/ack, опыт и знания.
В 2009 я кажется уволился с работы электроником и искал новую работу. Из универа меня уже отчислили.
И нет, это не опечатка, у меня реально в трудовой написано «электроник»
Альтернативное мнение, как и мнение альтернативно одаренных не стоит учитывать, себе доорже выйдет.
Мое мнение, что инструмент под задачу, а не растить монстра из одного инстнумента. Приведем тот же пример с бекапами. Бекап нужно
а) Создать. Скопировать файл, сделать дамп базы, etc.
б) Перенести в место, где он будет хранится. Иметь возможность настроить правила типа «Хранить Х бекапов за срок Y», удалять старые бекапы и далее.
в) Проверить бекап. А не нулевой ли у нас дамп? А не побился ли файл при сохранении? И далее, далее. Gitlab учит нас этому :)
г) Как-то восстановить бекап.
Это мои базовые требования к системе, которая делает бекапы. Все на основе личнгого опыта и опыта коллег. Что-то меньшее — не имеет смысла, потому что я просто не буду ему верить. Делать все это на ansible? Ну… каждый развлекается как хочет. Но вот в продакшене я бы за такое бил по рукам :)
Да, надо писать свои модули. А как иначе? :)
Касательно удаленного файла, у вас небольшая ошибка. Мы описываем состояние, а не действия. То есть мы не хотим удалить файл. Для нас важно, что файла нету. То есть это по факту один модуль, который в самом простом случае выполняет команду rm -rf path || true.
Да, все роли должны быть идемпотентными. Потому что иначе будет больше геморроя, чем пользы.
НЕ НАДО использовать ansible для бекапа. Тут справится и bash скрипт.
Изменение в инфраструктуре ОБЯЗАНО быть идемпотентным, потому что плейбук описывает состояние К которому надо привести систему, а не действия которые надо выполнить.
Весело
Это проблема любой организации с большой вертикалью управления.
Хотя я конечно и не пишу проекты на 100+ тысяч строк
Как человек, побывавший со всех сторон сервис деска, могу сказать, что регламенты придуманы не просто так. Да, они могут быть устаревшими, глупыми (и потому надо пересматривать), но писать в заявке всю необходимую информацию нужно хотя бы потому, что сервисный инженер не может залезть в голову писавшему и вынуть все.
На одной работе заявку написанную не по регламенту просто закрывали, со ссылкой на регламент, во второй раз — закрывали и пересылали руководителю с пометкой «сотрудник не читает регламенты», в третий раз — пересылали руководителю руководителя. Четвертого раза как-то не вспомню :)
Естественно, за перегибы могли вздрючить и сервисника. Нефиг докапываться до мелочей, думать-то все равно надо головой, а не регламентом.
Если вы интересуетесь инфраструктурой и не делаете так — честь вам и хвала, но не все же разработчики такие?
Про C# или Delphi поверю вам на слово — никогда с ними не работал.
IDE — это именно текстовый редактор с плагинами. Автокомплит, подсказки, и все остальное — плагины. Остальное — умение использовать sed/grep/awk/ack, опыт и знания.
Мы не говорим про Java, да. В ней без IDE никак.
И нет, это не опечатка, у меня реально в трудовой написано «электроник»
Мое мнение, что инструмент под задачу, а не растить монстра из одного инстнумента. Приведем тот же пример с бекапами. Бекап нужно
а) Создать. Скопировать файл, сделать дамп базы, etc.
б) Перенести в место, где он будет хранится. Иметь возможность настроить правила типа «Хранить Х бекапов за срок Y», удалять старые бекапы и далее.
в) Проверить бекап. А не нулевой ли у нас дамп? А не побился ли файл при сохранении? И далее, далее. Gitlab учит нас этому :)
г) Как-то восстановить бекап.
Это мои базовые требования к системе, которая делает бекапы. Все на основе личнгого опыта и опыта коллег. Что-то меньшее — не имеет смысла, потому что я просто не буду ему верить. Делать все это на ansible? Ну… каждый развлекается как хочет. Но вот в продакшене я бы за такое бил по рукам :)
Да, надо писать свои модули. А как иначе? :)
Касательно удаленного файла, у вас небольшая ошибка. Мы описываем состояние, а не действия. То есть мы не хотим удалить файл. Для нас важно, что файла нету. То есть это по факту один модуль, который в самом простом случае выполняет команду rm -rf path || true.
НЕ НАДО использовать ansible для бекапа. Тут справится и bash скрипт.
Изменение в инфраструктуре ОБЯЗАНО быть идемпотентным, потому что плейбук описывает состояние К которому надо привести систему, а не действия которые надо выполнить.
Сейчас наверное «чистой» Unix не осталось, она же коммерческая. Та же BSD хоть и ближе, чем GNU/Linux, весь UNIX код оттуда быстренько выпилили.