Комментарии 48
Особенно порадовало
И все это с учетом on-call в выходные.
Очень специфический рейт, возможно, не до конца понятный тем, кто с американцами не работал:)
Закончилось все очень печально, ибо при малейшей бифуркации подобная система становилась нежизнеспособной. 100 человек команды были гораздо адаптивнее, чем паровые двигатели. И могли бы как-то выкрутиться. Возвращаясь к гандикапам, мужчина, прибежавший с мешком, может и без мешка быстрее бегать, и жену вместо мешка взвалить на плечи, и бежать с такой же скоростью.
Подозреваю, что и транснациональная корпорация, в которой будет работать условных 3 DBA, а все, что только можно автоматизировать, будет автоматизированно, и скрипты будут раскатываться на десятки тысяч виртуальных машин, — идея утопическая. Ибо, да, их скрипты будут идеально работать в стерильных условиях, но стоит случиться хакерской атаке/ серьезному софтовому багу с порчей данных/ регуляторному маразму/ странной хотелке регионального менеджера, и тупо не хватит рук в момент, когда скрипты не смогут покрыть новый сценарий. Как бы не противно это было признавать, но 100 индусов куда адаптивнее ста скриптов.
Эти самые 1,2,10,100 DBA — это проект. У которого есть менеджер. А у менеджера есть цель — и эта цель это не счастье конкретно взятого DBA. Эта цель — стать крутым менеджером. А крутой менеджер — это кто? Это менеджер с кучей сотрудников = большим бюджетом. Вот сколько вы там на трех DBA получите… Ну мульен, ну два… А на 100 индусах — много. Плюс еще и штук 10 крутых надо будет нанять, что б за остальными убирали.
Так что фигвам, а не автоматизация.
Во-первых, не самая хорошая идея всех 100 подчинять одному менеджеру. Можно по 1-2-3 индуса отсыпать на продукт/проект, чтобы они были более вовлечены и лучше понимали, о чем идёт речь. И вокруг этой идеи крутятся почти все концепции современного ит, что нужны маленькие независимые самодостаточные юниты. И, будь я на месте менеджера одного из 25 бизнес-юнитов, предпочёл бы 2х индусов, но дедикейтед, чем 3х суперменов, но которым лишь могу закидывать таски и ждать, пока до меня очередь дойдёт.
Во-вторых, автоматизаторы-супермены плохо заменимы. Если завтра, например, их купят всей командой в инфраструктурный стартап, который пилит распределенную отказоустойчивую мультипарадигменную СУБД на блокчейне, где задачи и вызовы конкретно для них поинтереснее будут, то закрыть дыру будет ой, как непросто. Запасы индусни то пополнить куда проще.
Про ваш пример про парусник. Интересно, что развитие показало, что авторы парусника были концептуально правы.
Сейчас гигантские корабли почти полностью автоматизированы, и там, где была раньше толпа кочегаров и сменные on-call механики, на судне ровно один механик, который вахту не стоит, а занимается обслуживанием, профилактикой и ремонтом.
В российской компании вашего знакомого быстро заклеймили бы лентяем и повесили на него другие дела.
Да, у нас есть плюсы
В иностранных компаниях ответственность обговаривается. Если что-то не твоё — не делаешь. Если ты справляешься со своими обязанностями — ты хороший специалист, если нет — то нет.
Нельзя сказать, что работает как часы, но работает достойно, еженедельно до 7 стейджей пересоздает из оригинальых баз в 1+ ТБ объемом.
Команда 5 человек. 1 на обрезке/обезличке, еще 4 — выгрузка дампов/загрузка дампов/создание темплейтов/деплой темплейтов/реконфиг + создание интерфейсов для конечных пользователей, отчётов, работа с виртуализацией, работа с терраформом, етц.
И самое главное — этим пользуются.
Высокие каблуки
Не может быстро бегать
«я живу в безопасных условиях»
Чушь несусветная.
Высокие каблуки делают ноги визуально длиннее, а попу — подтянутее. В целом фигура становится более длинноногой — а длинноногие бегают быстрее, потому и нравятся мужчинам больше.
Если бы эволюция действительно шла в сторону гандикапа «не может бегать» у женщин, то мы бы сейчас наблюдали не стройные женские ножки, а ласты а-ля тюлень.
Аналогично и по остальным вашим фантазиям:
Длинные волосы
Сами по себе длинные волосы не показатель ничего.
А вот длинные и пышные, здоровые волосы — это показатель здоровья самки. Именно поэтому дамы со здоровыми, блестящими волосами нам приятны и прельстивы.
Цепляние за кусты и прочие ужасы — ну то такое. В культурах, где волосы не стригут и много лазят по лесам, шевелюру научились прятать в плотные прически (а иногда и в специальные футляры).
Узкая юбка/платье
Подчеркивает фигуру (особенно бедра). Широкие округлые бедра — это легкие роды, а следовательно и плодовитость.
Длинные ногти
Просто привлекают и фиксируют внимание. Функция аналогична бусам из клыков медведя на груди у папуаса.
Ваш тезис про «беззащитность» особо порадовал. Вообще-то животные с длинными когтями весьма опасны (ленивцы не в счет), а уж ярко-красные длинные ногти так и кричат о хищном разрывании мяса руками.
Заметная одежда с рюшечками
Привлекает внимание.
Тезисы про то что ее «надо стирать» — высосаны из пальца. Любую одежду надо стирать или чистить.
И вообще, если уж мы про эволюцию, то у людей практически нет гандикапов. Разве что женские сиськи. Да и те не сказать чтоб сильно мешали жить.
"длинноногие бегают быстрее, потому и нравятся мужчинам больше."
Мужчины любят не тех, кто от них быстро бегает, а тех, кто позволят себя догнать (быть может, изображая попытку к быстрому бегу)
"В культурах, где волосы не стригут и много лазят по лесам, шевелюру научились прятать в плотные прически (а иногда и в специальные футляры)."
Специальный футляр, который вынуждены носить? Вот вам типичный гандикап
ленивцы не в счет
Еще как в счет. Помню в детстве читал книгу Джеральда Даррела, так там был эпизод, как у него сбежал ленивец из клетки и каких трудов стоило его обратно упихать…
Ну наконец-то кто-то это написал. А то автор вообще не понимает, зачем женщине каблуки)) мужчин исторически привлекают три параметра: здоровье, красота (которая суть алертность) и игра в "охотник-жертва".
Разум может выдвигать другие критерии, но это на подкорке.
Не знаю, американец, что тебе посоветовать.
А вы его спрашивали, нужен ли ему этот совет? У него, вроде бы, всё хорошо. За годы с создания скриптов автоматизации бизнес не закрылся. Пользуются там ими или не пользуются — десятое дело. Кроме того, для него «автоматизация» это не только настроенные джобы, это ещё и какой-нибудь восточно-европейский или индийский специалист, которому можно пойти сказать «а ну пойдит разгреби вот это» — и он пойдёт и разгребёт. И это нисколько не сложнее запуска джоб. И даже не очень дороже.
в пятницу почти не работает… он по пятницам саморазвивается… это возможно, если у людей есть свободное время
Резюме: на работе есть свободное время. Это «винегрет»: свободное время это время, которое тратится на «саморазвитие». Рабочее время тратится на создание новой стоимости. Постольку рабочее время уже продано работодателю (продана рабочая сила на определенное время, конечно), то саморазвитие в рабочее время есть «кража».
Или по вашему физик должен думать о формулах с 9 до 18?
Ответ на ваш вопрос: физик в рабочее время занимает поставленной ему задачей.
Пример, «физика» занимающегося в рабочее время своими делами и что из этого получается — С.П. Королев.
Бывает, что работодатель начинает считать, что его обкрадывают и закручивает гайки. Но тогда от него бегут все продуктивные работники…
Я сейчас серьёзно думаю над проблемой сгнивания документации и процессов (когда код уползает, а документация — нет). Пока что лучшее, что я придумал, это сделать документацию машиночитаемой и валидировать в CI.
Вообще, скрипт, не интегрированный в реальность, это страшная штука. Например, был скрипт, который может восстановить базу данных в продакшене. Он дропал базу данных и восстанавливал все таблицы, которые там должны быть.
Прошли годы. От старых таблиц осталось половина, зато добавилось 100 новых, где самое важное.
И вот у нас инцидент и люди запускают скрипт восстановления бэкапа… И он дропает базу. И восстанавливает 50% от тех таблиц, которые он знает. И 0% от таблиц, о которых он не знает.
Вот по-этому скриптов и боятся. Они написаны для другого окружения (в прошлом). Чтобы скрипту можно было доверять, он должен быть или программой, или иметь доказательства своей актуальности.
В контексте восстановления базы данных — например, быть частью CI/CD при релизе новой версии ПО. Новая версия ПО проверяется против существующих бэкапов, скрипт восстановления бэкапов проверяется против новой версии ПО; обоим этот вопрос можно доверить.
… Не после каждого релиза, а перед релизом. Обнаружить, что свежевыкаченное ПО несовместимо с бэкапом на уровне "нет вам больше бэкапов" после релиза — печалька.
Повторю, трушный путь (для in-house приложений), это включение "database recovery" в один из сценариев, которые CI должен пройти. Не можешь восстановить? " Build failed" в CI, а не "сломался скрипт проверки бэкапа, мы не знаем что делать".
… Вы как-то странно представляете себе процесс релиза. Релиз, это то, что происходит после CI. Называется CD. Прошёл тесты? Фигак, на продакшен. Даже если там где-то в процессе есть человеки, это всё равно часть 'I'.
… Я понял в чём разница. У вас это делают люди (проверять, иметь план отката), а у меня роботы, которые плана не имеют, зато имеют алгоритм.
А у нас есть спец человек с правами на посмотреть на одну базу, спец человек с правами посмотреть на вторую, спец человек с правами на скопировать что-то с одной во вторую… ну и далее по пунктам.
И каждый релиз — это весело, движуха, новые открытия, челендж, вот это вот все!!!
Романтика…
"Я сейчас серьёзно думаю над проблемой сгнивания документации и процессов (когда код уползает, а документация — нет). Пока что лучшее, что я придумал, это сделать документацию машиночитаемой и валидировать в CI."
Тоже постоянно с таким сталкиваюсь.
Поменялись настройки, пусть даже немного — и надо править документацию. Которую пользователи ещё и не читают…
Лучшее, что приходит в голову — активно использовать BPMN, а текстовую часть оставить по возможности маленькой и только для пояснения людям. Полностью проблему не решит, но помочь может...
И 0% от таблиц, о которых он не знает.
А по идее должен был сказать перед дропом "это не те дроиды, которых вы ищете".
Первый раз слышу про скрипт восстановления базы данных, который бы ругался на содержимое базы, которую заменяет.
Причина? Потому что базу восстанавливают после… плохого. Например, после юного падавана, сделавшего миграцию не того не туда. Будет очень смешно обнаружить скрипт восстановления, который отказывается починить за юным подаваном, потому что в базе найдено "что-то лишнее".
Хотя мне доводилось контроль продуктовой базы делать для одного специфичного проекта, она была в закрытом контуре и штатно обновление этой базы происходило с usb-свистка. Продуктовую запрещалось изменять, но в экстренных случаях приходилось и изменения забывали передавать в эталонную, потому и контролировалось, чтобы не накатить лишнего. Потом всё переделали, конечно =)
Я считаю, что гандикап тут непричём. Или не совсем причём. Ближе всего к истине комментатор с кораблём на 100 индусов, но он не до конца развил мысль.
Причина такого положения вещей в том (если набрать распил бюджета), что эти задачи на самом деле ПО НАСТОЯЩЕМУ не автоматизированы. Их автоматизация не доведена до нужного технологического уровня. Кроме того, текущий уровень технологий может вообще не позволять это сделать за приемлемые ресурсы. В этом смысле и скрипт и 100 индусов — почти равнозначное костыли, только у индусов меньше рисков.
Такое постоянно встречалось в человеческой истории, корабли выше тому яркий пример.
Так вот я для себя понял, что вот это время оборота — единственное, что определяет гибкость проекта. Длинна петли. Сколько максимально может пролежать тикет до его решения. И в современных парадигмах управления, этот показатель стараются нацеленно уменьшать. Вкладываться в это. Тратить на это ресурсы. Это называется Continuous Delivery.
А если у тебя нет налаженных процессов контроля качества и ты работаешь от презентации до презентации и все твоя крутость заключается в умении красивно бить себя в грудь, тебе никакая автоматизация не поможет, а создаст только больше давления. И для себя я ситуацию подытожил так: проект не готов к автоматизации. И просто ушел из проекта. Проложил им путь, настроил инструменты, поставил архитектуру, сделал стартовый набор тестовых сценариев, показал что оно работает. Но продолжать этот путь они будут без меня.
Получается, если твой проект рассчитан на 5 лет, то вкладываться в CD ты не будешь, ты будешь работать именно сжигая человеческий ресурс, тем более тебе платят за человекочасы. Не машиночасы, а человекочасы. Окупаемость при таком раскладе менее важна, важно закончить проект в срок и чтобы один босс, показал более крупному боссу, что он довел этот проект до завершения. Или можно готовить три конверта.
Вкладываться в CD имеет смысл там где проект надолго и нужно уменьшать затраты.
Ну так вот к чему я это все.
Перед тем как браться за автоматизацию, нужно попытаться понять, а поможет ли оно им, и если нет, вежливо раскланяться и оставить на произвол судьбы. Это тяжело, хочется помочь. Но нельзя. Иначе проект начнет развиваться не в ту сторону. Он обрастет автоматизацией на неокрепших костях, которые просто сломаются под общей нагрузкой. И как тяжело потом будет осознавать, что своим желанием проявить свои навыки, желанием помочь, ты ускорил гибель проекта.
Неотправленное письмо боссу в кровавом Enterprise