phillennium Mar 26 2019 at 13:27

У нас DevOps. Давайте уволим всех тестировщиков

14 min

36K

JUG Ru Group corporate blogIT systems testing*Web services testing*

+38

Comments 38

amarao Mar 26 2019 at 13:38

Меня смущает, что SRE записан в тех, кто готовит delivery pipeline для продукта. Это как раз и есть 'devops'. А SRE — это человек, который реагирует на факапы и готовит инфраструктуру для реакции на них. Т.е. это reactioning side, считай, тот же саппорт, в котором эникейщика заменили на сеньёр-разработчика/администратора. Вроде бы и саппорт (сайт не работает!), но может пойти и поправить всё, и написать потмортем исследование с указанием на root cause даже если он сидит где-то в потрошках ядра.

Devops же — это человек, который delivery pipeline делает. Как именно оно пакетируется, тестируется и выкладывается. Пусконаладчик конвейера.

-2

phillennium Mar 26 2019 at 14:21

Devops же — это человек, который...

Очень многие на этом месте возразят, что говорить «девопс — это человек, который...» примерно то же, что говорить «аджайл — это человек, который...». Это не человек, это подход.

chupasaurus Mar 26 2019 at 14:33

В отличии от человека-аджайл, все друг друга понимают, вот такой парадокс.

amarao Mar 26 2019 at 15:37

Мне нравится ваша ссылка. Там такое количество уточнений и самоопроверждений и вопросиков за инсточниками, что просто ах.

А на самом деле — devops — это человек, который занимается devops'ом. Может включать в себя как разработчика, так и оператора.

jbaruch Mar 26 2019 at 18:33

DevOps это "set of development practices", не человек. SRE имплементирует эти практики.

TheYellingChives Mar 27 2019 at 11:03

Да, красиво, только что в инете прочитал как раз нечто подобное. DevOps это интерфейс, а SRE это его имплементация.

chupasaurus Mar 27 2019 at 14:09

Красиво малюете, вот только SRE не имеет отношения к процессу разработки до приёмки в production.

jbaruch Mar 27 2019 at 17:03

Ну книжку-то почитайте.

amarao Mar 26 2019 at 13:42

А, да, ещё один момент. По поводу «Важно лишь то качество, которое видит клиент». Забывают уточнить, «кому важно».

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

UFO just landed and posted this here

chupasaurus Mar 26 2019 at 14:17

Что собственно при таком подходе может вылиться в «у нас техдолг размером с Титаник, клиент не увидит новых фич ближайшие полгода-год» и тут у бизнеса появится непреодолимое желание позакручивать гайки.

amarao Mar 26 2019 at 15:34

Давайте на секунду заменим software engineers на врачей. Есть бизнес, у которого задача — обеспечивать прибыль, максимизируя количество фич, выкатываемых клиенту (за деньги клиентов).

Вопрос: должно ли медицинское учреждение максимизировать количество проводимых операций (по сравнению с числом медосмотров), т.к. операции приносят большую прибыль? Следует ли медицинскому учреждению отказаться от вакцинации? (Логика такова, что чем больше вакнцинаций, тем меньше обращений с болезнью). Следует ли повышать производительность труда хирургов, сокращая время между обращением пациентов и завершением операции? Можем ли мы во имя повышения эффективности увеличить число операций в год (каждая операция значительно менее инвазивная, и мы делаем клиенту несколько десятков малоинвазивных операций в день вместо одной операции раз в пять лет)?

chupasaurus Mar 26 2019 at 15:55

Под «таким подходом» я подразумевал тот, что вы процитировали из статьи, моя ошибка в формулировке.

23derevo Mar 26 2019 at 15:06

У вас всегда будут и проблемы, видимые клиенту, и проблемы, которых клиент не видит. При прочих равных проблемам, видимым клиенту, имеет смысл давать больший приоритет.

amarao Mar 26 2019 at 15:35

Именно так думают создатели лифтов. Вы видите тормозные системы лифта? Нет. Вы видите светящиеся красивые кнопки? Да.

Что должен предпочесть создатель лифта? Дизайн кнопок или система аварийного торможения?

WraithOW Mar 27 2019 at 12:45

Вы видите тормозные системы лифта? Нет.

Строго говоря, тормозная система — это не проблема, а решение проблемы падения лифта и превращения пассажиров в желе. Для пассажира такая проблема очень заметна, поэтому она и решается в первую очередь, а вы её не видите, потому что она уже решена. Вроде всё сходится.

amarao Mar 27 2019 at 15:02

Но вы же не видите её, правда?

Stanislavvv Mar 27 2019 at 16:19

Потому что потребители тут — владельцы здания, а не те, кто по нему ходит.
Потребители — видят фичу.

Neusser Mar 26 2019 at 17:03

Водитель не видит примерно 99% того, что есть в его автомобиле. Более 99% водителей никогда не столкнутся со многими ситуациями. Но те, кто столкнется, будут очень благодарны, что разработчики и тестировщики более 90% времени занимаются именно тем, о чем большинство водителей даже не подозревают.

amarao Mar 26 2019 at 17:10

Забавно, но автоиндустрию заставляют этим заниматься (А уже потом результаты используются в PR самих автопроизводителей). История автомобильной безопасности началась со скандалов со смертностью при авариях, после чего создали госорган по регуляции этого (США), который и начал требовать безопасности, вводил силком систему тестирования надёжности при авариях и т.д.

jbaruch Mar 26 2019 at 18:35

Кому важно: Клиенту, конечно. Поэтому, бизнесу. Всё. Что там от разработчиков требует этика не интересно никому.

Я понимаю, в чем проблема, в дословном понимании слова "видит". Не надо понимать это дословно. Важно то качество, с которым клиент взаимодействует. Clean code у вас в проде, или спагетти на Коболе — всем наплевать, если система работает.

-2

SuperKawai Mar 26 2019 at 14:14

Решил устроиться тестировщиком значит...(

PkXwmpgN Mar 26 2019 at 17:50

Консультант по эффективности и Developer Advocate это одно и тоже?

jbaruch Mar 26 2019 at 18:36

Консультант по эффективности ищет способы всех уволить. Developer Advocate – наоборот. Как это может быть одно и то же?

UFO just landed and posted this here

Neusser Mar 26 2019 at 18:32

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

jbaruch Mar 26 2019 at 18:38

Да, я знаю что такое силос. Как же хорошо, что мой доклад дал вам возможность блестнуть эрудицией (или нет).

vsantonov Mar 27 2019 at 00:05

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

Крайние исследования прогнозов на выборах в США, как бы намекают…

-1

jbaruch Mar 27 2019 at 00:15

Как и на любых выборах, на последних были хорошие прогнозы, и были плохие. Размер выборки был у всех примерно одинаковый (в отличие от качествa). Кроме того, подвел их ellectoral college, которого в исследованиях DevOps не существует.

khanid Mar 27 2019 at 11:40

Всегда когда читаю о девопсе, не покидает мысль, что читаю об эникействе gen. 2.

JuniorIL Mar 27 2019 at 14:51

Развейте хоть мысль, коль её написали, ибо я вообще не понял о чем Вы.

khanid Mar 27 2019 at 15:19

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