⁠
имхо не совсем
⁠
сбор боли - это часть работы
Oleg
так не надо
⁠
иногда команда думает что знает про боль, но все может разрулиться не совсем так, как они хотят
⁠
просто потому что ничего слаще морковки не ели
Oleg
тут есть интересный парадокс - если в компании ничего не болит, то она и нового человека не наймёт. а если болит - то ей новый человек не поможет. ведь боль это симптом дисфункциональности существующей команды, если бы они были способны меняться - то боли бы и не возникло, а если не способны - то вчера взятый с улицы мидл их и не заставит
⁠
нет, под болью я имею ввиду именно "хотелки"
⁠
то что команда хочет, но ввиду отсутствия капасити или компетенции не может
Oleg
хотелки - второй верный признак дисфункиональности команды
⁠
с чего бы?
⁠
вот например один из моих кейсов
⁠
команда очень хотела удобное средство просмотра логов с крупной платформы
⁠
команда не просто получила елку в итоге, а все команды проектов получили автоконфигурируемую елку с учетом нужд всех проектов
⁠
таким образом боль преобразовалась в солюшен
Oleg
если команды не дисфункциональна - то вместо хотелок у неё постоянный налаженый процесс анализа узких мест и культура экспериментов и изменений
⁠
ну это в идеальном мире
⁠
увы, в реальном чаще именно боль и хотелки
⁠
девелоперы часто хорошо разбираются только в своих инструментах и имеют очень слабую подготовку в общеупотребимом опенсорсе
Anonymous
девелоперы часто хорошо разбираются только в своих инструментах и имеют очень слабую подготовку в общеупотребимом опенсорсе
Как Вы изящно выразились, сударь. Я бы сказал, что прогеры вообще мало что понимают за пределами своего узкого круга задач. К примеру ноджиесер может вообще не понимать, что такое NAT... Да и вообще разбираться в сетях на уровне главбух-бабки.
Anonymous
Вот поэтому и нужны девопсы )))
Anonymous
Хехехе... это такой мимикрировавший эникей ))) В семье не без урода
Oleg
в компании должен быть постоянный налаженный процесс, который помогает всем 1) понимать что происходит 2) как всё устроено 3) что такое хорошо и что такое плохо. к сожалению, в усреднённой компании, такой процесс создать долго и сложно, ибо реальность обычно настолько неприглядна, что психологически проще её не осознавать 🙂
Oleg
почти для любой боли/хотелки root cause всегда будет одно из двух - или ваше отсутсвие культуры, или ваша тотальная некомпетентность (хотя почему или)
Oleg
вопрос "а может быть в консерватории что-то подправить?" обычно тонет в болоте всяких KPI
⁠
это утверждение сродни "работать надо только на facebook/google"
⁠
потому что остальные компании в чем-то хуже
Oleg
не вижу связи
⁠
я не думаю, что подобный процесс налажен хотя бы в 50% российских ИТ компаниях
rus
это утверждение сродни "работать надо только на facebook/google"
Почитай эту книгу https://www.ozon.ru/context/detail/id/33537490/ Там подробно написано почему ты не прав в этом утверждении =)
Oleg
скорее наоборот - в маленьких компаниях всё может быть не так плохо, я специально использовал слово "в средней"
⁠
у маленьких компаний как правило нет денег на выделенного девопса
⁠
и в таких случаях начинают требовать понимание облаков и контейнеризации от девелов
rus
Книга реально хорошая, к слову. Можно на цитаты растаскивать только так =)
Oleg
понимание облаков и контейнеризации от девелов - это и есть девопс
⁠
> Год выпуска 2015
rus
Это вообще не важно.
⁠
ну...может и стоит, но я обычно историей не увлекаюсь)
Oleg
выделенный девопс отдел - это как раз антипаттерн
⁠
я не про отдел
⁠
я про человека
⁠
придется смириться с тем, что в рф уже устоялось называть так системного инженера)
rus
ну...может и стоит, но я обычно историей не увлекаюсь)
Там вообще не про это. Там нетленочки.
⁠
я ващет писал это к утверждению выше
⁠
про то что обязательно должен быть процесс
⁠
если процесса нет - выпадать в кернел паник
⁠
часто ситуация выглядит так:
⁠
компания нанимает первого системного инженера по компетенции девопс
⁠
и ждет что он будет творить свою магию
Dima
Ну откровенно говоря вопросы уже больше к сетевому инженеру. Просто у нас привыкли что один человек должен пакеты собрать, мониторинг настраивать, джуниперы конфигурировать, катриджи менять, проектировать электро проводку, по пути программировать. Ну ещё кофе готовить и кофеварки чинить. И зовут его или админ, или дев опс или эникей.
⁠
а ему необходимо приводить запущенный бардак в порядок
Dima
Кстати любителей рассуждать о OSI всегда спрашиваю "И как вам эти знания пригодились на практике?" Обычно половина залипает на этом вопросе. Можно ещё спросить где вы встречали на практике именно OSI а не TCP/IP и в чем отличия.
Jenny
О_о
Старый
нет, это не так
я уже писал об этом, в рф devops это 10050 рукое существо
Anonymous
И минет еще сделает
Ну это уже зависит от...
Старый
И минет еще сделает
минет эт слабо, туалетную бумагу заменит своим языком
Anonymous
Ну это уже зависит от...
Мне кажется, раз он согласился настроить докер сворм, минет для него сделать - плевое дело
Старый
слушая тут некоторых товарищей, они именно это и делают
Anonymous
После сборки серваков-то
Старый
После сборки серваков-то
тут многие пишут раз в 10 больше, мне особенно нравится, когда хотят разраба который админит и з\п ток половины от разраба
Anonymous
Понятное дело, что в БОЛЬШОЙ конторе, где овер1000 сетевого оборудования, овер 5000 серверов, овер 100к контейнеров будет разделение. Но в любом случае...
Anonymous
Отдельный? Зачем?
Anonymous
Сетевик не нужен вообще, сорян
Anonymous
Передайте в чатик "нетворк трактор"
Anonymous
Что он будет делать? Циски переконфигурять каждый день?
Anonymous
Не читаю его месяцами и норм себя чувствую
Старый
Что он будет делать? Циски переконфигурять каждый день?
правильно сети делать, преоктировать их и тд, чтобы devops уже тупо писал в плейбуки готовое а не сам выдумывал
Anonymous
Проектирование сетей происходит 1 раз
Старый
а то получится 8 подсеть на контору в 300 тел
Старый
Проектирование сетей происходит 1 раз
😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂😂
Jenny
Проектирование сетей происходит 1 раз
и это должен сделать девопс?