Как стать автором
Обновить

Комментарии 48

Особенно порадовало


И все это с учетом on-call в выходные.

Очень специфический рейт, возможно, не до конца понятный тем, кто с американцами не работал:)

Конечно, никто же не в курсе джетлага часов в 10 в среднем.

Давайте разовьем теорию с гандикапами. Как-то создали гигантский суперавтоматизированный парусник . За счет автоматизации всего и вся, его команда составляла лишь 18 человек, когда рыночным бейслайном для такого количества груза было 100+.

Закончилось все очень печально, ибо при малейшей бифуркации подобная система становилась нежизнеспособной. 100 человек команды были гораздо адаптивнее, чем паровые двигатели. И могли бы как-то выкрутиться. Возвращаясь к гандикапам, мужчина, прибежавший с мешком, может и без мешка быстрее бегать, и жену вместо мешка взвалить на плечи, и бежать с такой же скоростью.

Подозреваю, что и транснациональная корпорация, в которой будет работать условных 3 DBA, а все, что только можно автоматизировать, будет автоматизированно, и скрипты будут раскатываться на десятки тысяч виртуальных машин, — идея утопическая. Ибо, да, их скрипты будут идеально работать в стерильных условиях, но стоит случиться хакерской атаке/ серьезному софтовому багу с порчей данных/ регуляторному маразму/ странной хотелке регионального менеджера, и тупо не хватит рук в момент, когда скрипты не смогут покрыть новый сценарий. Как бы не противно это было признавать, но 100 индусов куда адаптивнее ста скриптов.
100 индусов скажуть аймьтоталльибльокедь, и на этом их адаптивность закончится. Но проблема не в этом, проблема в организации процесса.
Эти самые 1,2,10,100 DBA — это проект. У которого есть менеджер. А у менеджера есть цель — и эта цель это не счастье конкретно взятого DBA. Эта цель — стать крутым менеджером. А крутой менеджер — это кто? Это менеджер с кучей сотрудников = большим бюджетом. Вот сколько вы там на трех DBA получите… Ну мульен, ну два… А на 100 индусах — много. Плюс еще и штук 10 крутых надо будет нанять, что б за остальными убирали.

Так что фигвам, а не автоматизация.

Во-первых, не самая хорошая идея всех 100 подчинять одному менеджеру. Можно по 1-2-3 индуса отсыпать на продукт/проект, чтобы они были более вовлечены и лучше понимали, о чем идёт речь. И вокруг этой идеи крутятся почти все концепции современного ит, что нужны маленькие независимые самодостаточные юниты. И, будь я на месте менеджера одного из 25 бизнес-юнитов, предпочёл бы 2х индусов, но дедикейтед, чем 3х суперменов, но которым лишь могу закидывать таски и ждать, пока до меня очередь дойдёт.


Во-вторых, автоматизаторы-супермены плохо заменимы. Если завтра, например, их купят всей командой в инфраструктурный стартап, который пилит распределенную отказоустойчивую мультипарадигменную СУБД на блокчейне, где задачи и вызовы конкретно для них поинтереснее будут, то закрыть дыру будет ой, как непросто. Запасы индусни то пополнить куда проще.

Про ваш пример про парусник. Интересно, что развитие показало, что авторы парусника были концептуально правы.
Сейчас гигантские корабли почти полностью автоматизированы, и там, где была раньше толпа кочегаров и сменные on-call механики, на судне ровно один механик, который вахту не стоит, а занимается обслуживанием, профилактикой и ремонтом.

Это опять же стало возможно в стерильных условиях окружения. Маршруты прописаны до метра, график — до минуты. В любой точке маршрута есть связь, если что туда может быстро прибыть поддержка.

Да да, Evergreen согласен с вами.

Это работает в американской компании, но не в российской.
В российской компании вашего знакомого быстро заклеймили бы лентяем и повесили на него другие дела.

Да, у нас есть плюсы

Я боюсь неверно выразиться, но так получается, потому что в российских компаниях нет понятия зоны ответственности, за соблюдение которой вам платят. Опять же, никто не управляет так, как учат, а всё управление персоналом строится по принципу «как хочется». По идее, это нарушение трудового права.
В иностранных компаниях ответственность обговаривается. Если что-то не твоё — не делаешь. Если ты справляешься со своими обязанностями — ты хороший специалист, если нет — то нет.

НЛО прилетело и опубликовало эту надпись здесь
Ничего не мешает руководителю свалить свои дела или дела другого сотрудника на работника
НЛО прилетело и опубликовало эту надпись здесь
Мы делали подобный процесс в российской компании.
Нельзя сказать, что работает как часы, но работает достойно, еженедельно до 7 стейджей пересоздает из оригинальых баз в 1+ ТБ объемом.
Команда 5 человек. 1 на обрезке/обезличке, еще 4 — выгрузка дампов/загрузка дампов/создание темплейтов/деплой темплейтов/реконфиг + создание интерфейсов для конечных пользователей, отчётов, работа с виртуализацией, работа с терраформом, етц.
И самое главное — этим пользуются.
Высокие каблуки
Не может быстро бегать
«я живу в безопасных условиях»

Чушь несусветная.
Высокие каблуки делают ноги визуально длиннее, а попу — подтянутее. В целом фигура становится более длинноногой — а длинноногие бегают быстрее, потому и нравятся мужчинам больше.

Если бы эволюция действительно шла в сторону гандикапа «не может бегать» у женщин, то мы бы сейчас наблюдали не стройные женские ножки, а ласты а-ля тюлень.

Аналогично и по остальным вашим фантазиям:
Длинные волосы

Сами по себе длинные волосы не показатель ничего.
А вот длинные и пышные, здоровые волосы — это показатель здоровья самки. Именно поэтому дамы со здоровыми, блестящими волосами нам приятны и прельстивы.

Цепляние за кусты и прочие ужасы — ну то такое. В культурах, где волосы не стригут и много лазят по лесам, шевелюру научились прятать в плотные прически (а иногда и в специальные футляры).

Узкая юбка/платье

Подчеркивает фигуру (особенно бедра). Широкие округлые бедра — это легкие роды, а следовательно и плодовитость.

Длинные ногти

Просто привлекают и фиксируют внимание. Функция аналогична бусам из клыков медведя на груди у папуаса.

Ваш тезис про «беззащитность» особо порадовал. Вообще-то животные с длинными когтями весьма опасны (ленивцы не в счет), а уж ярко-красные длинные ногти так и кричат о хищном разрывании мяса руками.

Заметная одежда с рюшечками

Привлекает внимание.
Тезисы про то что ее «надо стирать» — высосаны из пальца. Любую одежду надо стирать или чистить.

И вообще, если уж мы про эволюцию, то у людей практически нет гандикапов. Разве что женские сиськи. Да и те не сказать чтоб сильно мешали жить.

"длинноногие бегают быстрее, потому и нравятся мужчинам больше."


Мужчины любят не тех, кто от них быстро бегает, а тех, кто позволят себя догнать (быть может, изображая попытку к быстрому бегу)

Каблук — это таки иллюзия длинной ноги. А на иллюзии далеко не убежишь. Во-всяком случае, пока киберпанк не выкатили в прод…
Есть даже забеги на шпильках :) И весьма быстрые.

Длинноногость и бег тут ни при чём) просто на цыпочках человек смотрится красивее, та самая алертность.

"В культурах, где волосы не стригут и много лазят по лесам, шевелюру научились прятать в плотные прически (а иногда и в специальные футляры)."


Специальный футляр, который вынуждены носить? Вот вам типичный гандикап

ленивцы не в счет

Еще как в счет. Помню в детстве читал книгу Джеральда Даррела, так там был эпизод, как у него сбежал ленивец из клетки и каких трудов стоило его обратно упихать…

Ну наконец-то кто-то это написал. А то автор вообще не понимает, зачем женщине каблуки)) мужчин исторически привлекают три параметра: здоровье, красота (которая суть алертность) и игра в "охотник-жертва".


Разум может выдвигать другие критерии, но это на подкорке.

игра в "охотник-жертва"
А я и не знал, что 131 УК РФ — механизм отбора.

Аоуыэх, просверливший первую дыру в камне, тоже не знал. Но механизм уже работал.

Описание «Самка вида homo sapiens с гандикапом» с табличкой параметров напомнило мысли Ивана Ефремова о женской красоте в романе «Лезвие Бритвы». )
Не знаю, американец, что тебе посоветовать.

А вы его спрашивали, нужен ли ему этот совет? У него, вроде бы, всё хорошо. За годы с создания скриптов автоматизации бизнес не закрылся. Пользуются там ими или не пользуются — десятое дело. Кроме того, для него «автоматизация» это не только настроенные джобы, это ещё и какой-нибудь восточно-европейский или индийский специалист, которому можно пойти сказать «а ну пойдит разгреби вот это» — и он пойдёт и разгребёт. И это нисколько не сложнее запуска джоб. И даже не очень дороже.

Да, все хорошо. До тех пор, пока не появиться компания делающая то же самое, но за счет автоматизации дешевле/быстрее/иногда лучше. И тогда бизнес умирает. Ну если вы только не монополия =)))

в пятницу почти не работает… он по пятницам саморазвивается… это возможно, если у людей есть свободное время


Резюме: на работе есть свободное время. Это «винегрет»: свободное время это время, которое тратится на «саморазвитие». Рабочее время тратится на создание новой стоимости. Постольку рабочее время уже продано работодателю (продана рабочая сила на определенное время, конечно), то саморазвитие в рабочее время есть «кража».
работа творческих людей без саморазвития невозможна
Или по вашему физик должен думать о формулах с 9 до 18?
Человек (никакой человек) не может прекратить мыслить, поскольку «мышление есть способ существования мыслящего тела». Если вы думаете, что ненормированность умственной деятельности своейственна только «творческим профессиям», то вы ошибаетесь. Слесарь, получив сложное задание, так же прикидывает как его надо выполнять. В т.ч. и в личное время.

Ответ на ваш вопрос: физик в рабочее время занимает поставленной ему задачей.

Пример, «физика» занимающегося в рабочее время своими делами и что из этого получается — С.П. Королев.

Это уже превратилось в норму. Работник не может найти условия, в которых по трудовому договору он занимается своими делами, когда ему скучно. А работодатель не может найти работников, которые абсолютно всё рабочее время посвящают работе.

Бывает, что работодатель начинает считать, что его обкрадывают и закручивает гайки. Но тогда от него бегут все продуктивные работники…
Похоже, в тексте не хватает главной картинки :)
image

Я сейчас серьёзно думаю над проблемой сгнивания документации и процессов (когда код уползает, а документация — нет). Пока что лучшее, что я придумал, это сделать документацию машиночитаемой и валидировать в CI.


Вообще, скрипт, не интегрированный в реальность, это страшная штука. Например, был скрипт, который может восстановить базу данных в продакшене. Он дропал базу данных и восстанавливал все таблицы, которые там должны быть.


Прошли годы. От старых таблиц осталось половина, зато добавилось 100 новых, где самое важное.


И вот у нас инцидент и люди запускают скрипт восстановления бэкапа… И он дропает базу. И восстанавливает 50% от тех таблиц, которые он знает. И 0% от таблиц, о которых он не знает.


Вот по-этому скриптов и боятся. Они написаны для другого окружения (в прошлом). Чтобы скрипту можно было доверять, он должен быть или программой, или иметь доказательства своей актуальности.


В контексте восстановления базы данных — например, быть частью CI/CD при релизе новой версии ПО. Новая версия ПО проверяется против существующих бэкапов, скрипт восстановления бэкапов проверяется против новой версии ПО; обоим этот вопрос можно доверить.

В смысле у вас случился инцидент? Бекапы и прочее рековери в идеале вообще после каждого релиза должно перепроверяться, а не раз в пару лет. Именно для проверки актуальности.

… Не после каждого релиза, а перед релизом. Обнаружить, что свежевыкаченное ПО несовместимо с бэкапом на уровне "нет вам больше бэкапов" после релиза — печалька.


Повторю, трушный путь (для in-house приложений), это включение "database recovery" в один из сценариев, которые CI должен пройти. Не можешь восстановить? " Build failed" в CI, а не "сломался скрипт проверки бэкапа, мы не знаем что делать".

Так до релиза он может и работать. Идеально — иметь DR прод, и проверять на нем в процессе релиза. Ну а если его нет — идеально иметь план отката на предыдущую версию. Работающий ;)

… Вы как-то странно представляете себе процесс релиза. Релиз, это то, что происходит после CI. Называется CD. Прошёл тесты? Фигак, на продакшен. Даже если там где-то в процессе есть человеки, это всё равно часть 'I'.


… Я понял в чём разница. У вас это делают люди (проверять, иметь план отката), а у меня роботы, которые плана не имеют, зато имеют алгоритм.

Ну вот видите как у вас скучно.
А у нас есть спец человек с правами на посмотреть на одну базу, спец человек с правами посмотреть на вторую, спец человек с правами на скопировать что-то с одной во вторую… ну и далее по пунктам.
И каждый релиз — это весело, движуха, новые открытия, челендж, вот это вот все!!!
Романтика…
Любой скрипт — это программа, пусть даже маленькая. Но программы, пусть даже маленькие, тоже надо учиться писать и тестировать на отказы. В частности, чтобы не допускать таких ляпов.

Скрипт, как алгоритм, кстати, проверяется тривиально, а в некоторых случаях даже проверяется глазами без проблем.


Вот что нетривиально — так это интеграционное тестирование (что оно работает с базой и бэкапом).

"Я сейчас серьёзно думаю над проблемой сгнивания документации и процессов (когда код уползает, а документация — нет). Пока что лучшее, что я придумал, это сделать документацию машиночитаемой и валидировать в CI."


Тоже постоянно с таким сталкиваюсь.
Поменялись настройки, пусть даже немного — и надо править документацию. Которую пользователи ещё и не читают…
Лучшее, что приходит в голову — активно использовать BPMN, а текстовую часть оставить по возможности маленькой и только для пояснения людям. Полностью проблему не решит, но помочь может...

И 0% от таблиц, о которых он не знает.

А по идее должен был сказать перед дропом "это не те дроиды, которых вы ищете".

Первый раз слышу про скрипт восстановления базы данных, который бы ругался на содержимое базы, которую заменяет.


Причина? Потому что базу восстанавливают после… плохого. Например, после юного падавана, сделавшего миграцию не того не туда. Будет очень смешно обнаружить скрипт восстановления, который отказывается починить за юным подаваном, потому что в базе найдено "что-то лишнее".

Ну просто непонятно как он восстанавливал и по идее последний бэкап должен быть максимально близок к упавшей базе.
Хотя мне доводилось контроль продуктовой базы делать для одного специфичного проекта, она была в закрытом контуре и штатно обновление этой базы происходило с usb-свистка. Продуктовую запрещалось изменять, но в экстренных случаях приходилось и изменения забывали передавать в эталонную, потому и контролировалось, чтобы не накатить лишнего. Потом всё переделали, конечно =)

Я считаю, что гандикап тут непричём. Или не совсем причём. Ближе всего к истине комментатор с кораблём на 100 индусов, но он не до конца развил мысль.


Причина такого положения вещей в том (если набрать распил бюджета), что эти задачи на самом деле ПО НАСТОЯЩЕМУ не автоматизированы. Их автоматизация не доведена до нужного технологического уровня. Кроме того, текущий уровень технологий может вообще не позволять это сделать за приемлемые ресурсы. В этом смысле и скрипт и 100 индусов — почти равнозначное костыли, только у индусов меньше рисков.


Такое постоянно встречалось в человеческой истории, корабли выше тому яркий пример.

Недавно пришел на новый проект делать там автоматизацию тестирования. Проект мне нахваливали как гибкий, современный и пр. На деле оказалось они месяц не могут закрыть найденый баг. Разрабы пинают его заказчику, заказчик возит его по совещаниям с другими подрядчиками, потом пинает девам. Те говорят этого нет в спецификации, нужно собрание по спецификации. Проводят, решают как должно быть. Попутно как обычно охреневают, что и вокруг этой проблемы тоже все в полной заднице. Но они уже к этому привыкли, главно на демо главному боссу показывать задницу красивой стороной. Конформизм цветет и пахнет.

Так вот я для себя понял, что вот это время оборота — единственное, что определяет гибкость проекта. Длинна петли. Сколько максимально может пролежать тикет до его решения. И в современных парадигмах управления, этот показатель стараются нацеленно уменьшать. Вкладываться в это. Тратить на это ресурсы. Это называется Continuous Delivery.

А если у тебя нет налаженных процессов контроля качества и ты работаешь от презентации до презентации и все твоя крутость заключается в умении красивно бить себя в грудь, тебе никакая автоматизация не поможет, а создаст только больше давления. И для себя я ситуацию подытожил так: проект не готов к автоматизации. И просто ушел из проекта. Проложил им путь, настроил инструменты, поставил архитектуру, сделал стартовый набор тестовых сценариев, показал что оно работает. Но продолжать этот путь они будут без меня.

Получается, если твой проект рассчитан на 5 лет, то вкладываться в CD ты не будешь, ты будешь работать именно сжигая человеческий ресурс, тем более тебе платят за человекочасы. Не машиночасы, а человекочасы. Окупаемость при таком раскладе менее важна, важно закончить проект в срок и чтобы один босс, показал более крупному боссу, что он довел этот проект до завершения. Или можно готовить три конверта.
Вкладываться в CD имеет смысл там где проект надолго и нужно уменьшать затраты.

Ну так вот к чему я это все.
Перед тем как браться за автоматизацию, нужно попытаться понять, а поможет ли оно им, и если нет, вежливо раскланяться и оставить на произвол судьбы. Это тяжело, хочется помочь. Но нельзя. Иначе проект начнет развиваться не в ту сторону. Он обрастет автоматизацией на неокрепших костях, которые просто сломаются под общей нагрузкой. И как тяжело потом будет осознавать, что своим желанием проявить свои навыки, желанием помочь, ты ускорил гибель проекта.

5 лет это долго! Это 2-5 поколений разработчиков

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.