имхо не совсем
сбор боли - это часть работы
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 раз
и это должен сделать девопс?