Комментарии 28
Вот чего я никогда не понимал (ещё меньше чем разделение труда между разработкой и эксплуатацией) — это разделение труда между разработкой и QA.
Ну то есть я осознаю, что есть целая индустрия QA, но мне тем не менее кажется противоестественным тот факт что говноко^Wпишут одни, а проверяют другие.
Если только во введении есть «вброс» про это, но в целом, конечно TestOps работает как для тестировщиков, так и для разработчиков, пишущих тесты.
Разные слои требуют разной специализации и квалификации. Правильно спланированная система содержит слои таким образом, что нижележащие слои предполагаются рабочими, а тесты фокусируются только на своём слое. Вот если кто-то в end2end тесте решает нафигачить тестов на "мусор в форме ввода" (утрирую), вот тут вот и начинается боль и плохо поддерживаемые тесты.
QA, вообще, должен быть частью release team, и задача qa — проверить свою работу (свой релиз). Тогда человек владеет компетенцией и чувствует продукт. Может так случиться, что окажется, что "своя работа" не работает из-за того, что предыдущий отдел фигню отгрузил. Такое бывает на каждом уровне, вплоть до "кривой версии libc с багом" или фиксом деления в процессоре.
Да и, собственно, какие такие есть особые квалификации у QA, которых нет у разработчиков?
Окей. Допустим, у вас сайт для машинного перевода. Ваша команда программистов знает ML, умеет писать (допустим, на окамле), пишет для него юнит-тесты. Ещё одна умеет его пакетировать (молодцы) и пишет (условные) chart'ы helm'а. Ещё одна умеет отлаживать куб и нижележащую ОС (упс, не слишком ли много?), решать проблемы с бондингом на сетевом оборудовании, может обновить прошивку в блоке питания и обсудить с главным энергетиком дата-центра расхождение фаз в двух вводах.
Вы уверены, что правильный подход? Или, лучше, положиться на нижележащие слои? Производитель процессоров даёт вам абстракцию, производитель ОС даёт вам абстракцию, libc даёт вам абстракцию, ваш язык программирования даёт вам абстракцию,… но тут всё прекращается, потому что "порочная идея".
unsound.
Окамлисты пишут свой сервис, тестируют его, собирают там пакет или образ и нажимают кнопку для деплоя его в CI/CD, который написали, протестировали и задеплоили люди, знакомые с кубом и хелмчартами.
Если что-то пошло не так, то квалификации окамлистов должно хватить, чтобы нажать другую кнопку в CI/CD и откатиться на предыдущую версию, починить баг и добавить регрессионный тест.
И все это весело бежит на железе, которое поставили, запитали и протестировали инженеры в ДЦ.
Конечно же я не хочу заставить каждого программиста начинать со сбора речного песочка для микросхем, на которых будет бежать его программа, не надо доводить идею до абсурда. Но проверить свой сервис без QA, задеплоить, поонколлить, откатить и отдебажить производительность без админа — можно и нужно.
Ага, а anycast вашей сети в bgp у вас тоже программисты на ocaml делают? А софт на сервере кто обновляет? Инженеры DC?
Потому что сначала вы говорите, что вы против разделения компетенций и за вертикальность, а в следующем посте у программиста в руках три кнопки в CI (которые им кто-то написал и протестировал, включая ситуации с авариями).
Вы определитесь, многорукие тьюринг-полные шивы, или всё-таки разделение обязанностей?
Сервис перевода — один продукт.
CI/CD — другой.
Серверная инфраструктура — третий, а сетевая — четвертый.
То есть сервер, на котором работает приложение — это другой "продукт"? Ну, тогда всё просто.
Программа серверного перевода — один продукт.
Услуга "перевод aas" — другой продукт.
ОС и система оркестрации — другой продукт.
Сервер, на котором крутится услуга — другой продукт.
Между каждым слоем — свои тесты. Сервер протестирован (хостером), хостер же отвечает за непрерывность электричества; ОС и оркестрация выкачена другой командой, прошла тестирование и мониторится ею же. Команда разработки сделала продукт и протестировала его (dev окружение, e2e, юнит-тесты и т.д.)
Команда эксплутации выкатила его в продакшен и следит за работоспособностью, при необходимости закатывая SRE-рукава и ковыряясь в потрошках.
Между каждым слоем контракт, который проверяется тестами. Каждый слой предполагает, что нижележащий сервис работает хорошо.
Если же у вас операционная работа лежит на программистах, то а) это on-call (попробуйте сеньёра уговорить на on-call), б) они занимаются безумиями, которые их не касаются (на мирроры апстрима влили фигю, надо откатить два сервера) в) многорукость шивы чревата поверхностностью.
Если же у вас операционная работа лежит на программистах, то а) это on-call (попробуйте сеньёра уговорить на on-call), б) они занимаются безумиями, которые их не касаются (на мирроры апстрима влили фигю, надо откатить два сервера) в) многорукость шивы чревата поверхностностью.
а) никакой проблемы, у нас все синьоры онколлят, и я сам онколлю. А если у какого-то синьора от онколла корона с головы свалится, так для всех будет лучше, если он пойдет работать куда-нибудь еще, благо пока еще есть выбор компаний, где-можно по-старинке говно за стенку админам перекидывать.
б) а почему это их не касается? Если это ломает их продукт, то вполне себе касается
в) это просто отмазка для тех, кому лень расширять свой кругозор, ну правда. Я очень хорошо представляю, какой необходим объем знаний для того, чтобы успешно совмещать разработку и эксплуатацию и вполне уверен, что это легко ложится в одну голову на более чем достаточном уровне.
Ого, как у нас теперь глубоко всё пошло. Во-первых, в рамках вашей модели мы должны поменять КЗОТ и существующие практики трудового законодательства. Во-вторых, мы должны поменять графики работы детских садов (сколько у вас детей в доме, когда вы и ваша супруга on-call)?
В целом, подход "многорукой шива с 24/7 availability" не является завершённым, потому что в в формулу ещё входит "за миску риса в день".
У нас сейчас админы работают в рабочие часы, без on-call. Включая 4 часа ночи по Мск, что соответствует комфортному рабочему времени смены в соотв. часовом поясе.
Внезапно, правильная организация рабочих процессов позволяет не тащить работу в жизнь людей.
А главное, это совершенно не похоже на утопию, которую вы тут описываете, когда разработчиков сдёргивают в 5 утра первого января, "потому что devops".
А если такой возможности нет, то почему тащить работу в жизнь админов можно, а в жизнь программистов — нет? Админ тоже человек, так-то.
Конечно, никому не нравится вставать по ночам и что-то чинить, ну что ж поделать — такая работа, перекладывать ее на кого-то еще — не совсем справедливо. А главное, совершенно неэффективно — я поработал с разными моделями отношений разработка — эксплуатация (как программистом, так и админом), и вполне в этом уверен.
Я предлагаю из диалога убрать спор про on-call. Есть devops модель (которая на самом деле) говорит, что "пусть разработчики и деплоят". И предлагает иметь инструменты для этого (ci/cd, красивые дашборды и т.д.). Как метод ускорения деплоя это хорошо, но ровно до того момента, пока программист не вынужден нырять глубже. Если он вынужден и рядом нет людей, которые имеют в этом специализацию, то это даунгрейд компетенции компании.
Более того, вот эти "ci кнопки" для разработчика тоже кто-то должен писать. Если это делает разработчик (условный senior), то он берёт на себя обязанности этого человека и показывает продуктивность уровня junior'а. (Потому что деплой — это вполне себе отдельная дисциплина, и условно, человеку нужно 2-3 года ежедневной практики на ансибле, чтобы писать на нём прилично).
В хорошей команде каждый человек "знает" в слой выше и ниже него. Админ может читать и писать код, и знает как сервера работают. Программист может писать и читать инфра-код и понимает как (условный сейлз) работает. Но у каждого своя компетенция и зона ответственности.
Чем больше concerns на человеке, тем более примитивными становятся его ответы на эти concerns. "Заткнули и ладно".
> Админ может читать и писать код, и знает как сервера работают
> Программист может писать и читать инфра-код и понимает как (условный сейлз) работает
Хорошо бы, но такого не происходит «само по себе», внезапно. Если программист не сидит на околле своего сервиса, то плевать ему на то, как там его код крутится на серверах, сколько он памяти и процессора жрет и как часто падает — если чо, админы поднимут.
Точно так же и условный админ никогда не полезет в код разбираться, почему падает сервис, он просто возьмет и откатит на какую-нибудь версию, которая работала раньше, и хоть трава не расти — с утречка погромисты посмотрят.
А вот когда человек по-настоящему «владеет» своим сервисом, когда он отвечает за него — вот тогда появляется настоящая мотивация слазить за пределы своего скоупа, и наверх, и вниз — и чтобы бизнес не клевал мозг за то, что «почему так медленно работаете, на каждый деплой по пять роллбеков», и чтобы сервис по ночам не будил, словив ООМ.
И это мы только рассмотрели один сервис в вакууме — все становится еще более интересно, когда этих сервисов десятки и сотни, и ответственность за их работоспособность и функциональнось размазана между разными сторонними людьми и ни у кого нет полного понимания, как же именно конкретный сервис работает.
Что же касается глубины знаний, нужных для того чтобы продуктивно крутить свой сервис самостоятельно — полноте вам, у погромиста не взорвется голова и не отвалится задница, если он иногда будет запускать какой-нить tcpdump или perf. А если и отвалится, то это даже к лучшему — будет мотивация навтыкать нормальных логов и метрик внутрь кода, а не гадать на стрейсе :)
Вот интересно. Вы пользуетесь браузером — и вам хорошо, что рядом нет программиста, который "если, что починит". И как-то у них получается. А в вашей модели — к каждому браузеру и к каждой операционной системе должен прилагаться программист, который её написал, и которому "не всё равно".
… Или интернет-магазин с лэндингом специальный случай, и он сильно сложнее, чем какая-то там операционная система?
… При этом эти программисты вечером уходят домой и им не звонят ночью. Кажется, вы только что продали agile. Agile, это когда программисты релизят часто и готовы чинить продакшен 24/7.
Вы весьма неприятным образом передергиваете, сравнивая коробочные продукты, такие как браузер и ОС, у которых нет эксплуатации как таковой (точнее, она делается другой стороной), и вещи вроде сайтов или других сервисов в интернете, которые пишет и эксплуатирует одна и та же сторона.
Вы правы в том, что есть существенная разница между ПО для широкого потребления и in-house продуктом. В случае in-house продукта его эксплуатация осуществляется той же компанией, которая разработала продукт.
Однако, это деление сугубо административно-финансовое. В одной компании уборщица в штате, в другой — аутсорс в клининговую компанию.
В принципе, наличие "единственного in-house пользователя" позволяет сильно срезать на качестве документации, границах интерфейсов, обещании стабильности, политике поддержки, бэкпортах фиксов и прочих весьма затратных вещах. После этого классическая эксплуатация становится уже невозможной, т.к. оказывается, что многие эксплутационные сценарии вообще не покрыты или покрыты частично. Такие проблемы закрываются привлечением к эксплуатации разработчиков. Теоретически, при фиксированном числе разработчиков, это позволяет экономить на operational team, поскольку разработчики и так и так есть, осталось их уговорить работать 24/7.
кажется противоестественным тот факт что говноко^Wпишут одни, а проверяют другие.Наоборот, противоестественно когда один человек и пишет и проверяет.
Объяснение очень простое: чужие ошибки мы замечаем быстрее и чаще, чем свои собственные. Так устроен человек.
Именно на этом основополагающем принципе построена вся индустрия тестирования.
Именно поэтому Хабр советует перед публикацией статьи дать прочитать её другому человеку, с «незамыленным глазом». HeadHunter советует сделать то же самое в отношении резюме, и т.д.
И именно поэтому в уважающих себя и своих читателей изданиях существуют раздельные должности для авторов, редакторов, и корректоров.
Всё-таки в отличие от текста на естественном языке, программы таки должны соответствовать определённым формальным требованиям и формальными методами должны и проверяться, метод пристального взгляда незамыленным глазом — это всё-таки не основной метод тестирования, не так ли? И я не понимаю, почему написание тестов должно делаться другими людьми.
Сразу станет понятна взаимосвязь «программы пишут люди => человеку свойственно ошибаться => чужие ошибки заметнее собственных».
Возможно, Вам будет понятнее теологическое объяснение: про соринку в своём глазу, и бревно за плечом другого.
Проблема в том, что после короткого изучения я понял, что есть те, кто пишет «как правильно» и те, кто пишет «как принято». Я в общении чаще слышу именно тест-сьют, к сожалению или к счастью. Но давайте сделаем «как правильно».
Задача тестировщика — тестировать, спору нет, а вот задача QA — обеспечить качество, и тестирование здесь далеко не основной инструмент. В лучшем случае оно частично отобразит уровень качества, в худшем — будет лежать мертвым грузом, как в вашей истории,. Но, в любом случае, качество продукта тестирование не задаст.
Статья интересная, многие советы действительно полезны, но если слова CTO "сделайте нормально" наталкивает вас только на мысли о рефакторинге test automation инфраструктуры, то это, на мой взгляд, не очень хорошо. И отсутствие слова "качество" на протяжении всей статьи должно настораживать.
TestOps: писать автотесты недостаточно