Size: a a a

SPb Reliability Meetup

2019 April 09

VR

Vasiliy Romaneev in SPb Reliability Meetup
Serg Martynov
Это не промывание мозгов. Это то, благодаря чему можно повысить свою компетенцию и заработную плату)) нельзя стать хорошим сеньером, архитектором и CTO без знания всех уровней на которых ведётся разработка и работает продукт.
то есть ты хочешь разработчикам раскрыть глаза, что вся история про клёвую архитектуру, нормализацию БД и прочие плюшки чистого кода - фикция.
Вместо этого - давай фича тогглинг, денормализацию БД и кеширование на всех слоях ?)
источник

DN

Dmitry Nagovitsin in SPb Reliability Meetup
Никто никому ничего не должен. Кто хочет - растет и зарабатывает. Кто не хочет - уютно стагнирует
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
Dmitry Nagovitsin
Это вообще вопрос, выходящий за инженерные рамки
боюсь не до конца понял, а где они эти рамки
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
Dmitry Nagovitsin
Никто никому ничего не должен. Кто хочет - растет и зарабатывает. Кто не хочет - уютно стагнирует
+1
источник

SM

Serg Martynov in SPb Reliability Meetup
Vasiliy Romaneev
то есть ты хочешь разработчикам раскрыть глаза, что вся история про клёвую архитектуру, нормализацию БД и прочие плюшки чистого кода - фикция.
Вместо этого - давай фича тогглинг, денормализацию БД и кеширование на всех слоях ?)
Почему, это тоже очень важно. Ноборот, разработчик, решая инфраструктурные задачи, должен писать клевый и понимаемый код. Тут важно понимать, что клевая архитектура и инфрастуктура это одно и то же, когда вы обслуживаете сервис. отличная инфраструктура не спасет вас от хреновой архитектуры и наоборот.
источник

SM

Serg Martynov in SPb Reliability Meetup
Я вынужден удалиться, на все вопросы отвечу сегодня на митапе ))
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
давайте поможем бедняжкам разработчикам понять, как надо работать называется:)
источник

VR

Vasiliy Romaneev in SPb Reliability Meetup
Я-то с тобой полностью согласен
разработчик должен быть в курсе как его код работает в реальной жизни.
но не согласен с поинтом, что сисадмин/devops/сре не нужны.
они нужны, как нужны тестировщики, т.к. у них отличный от разрабов mindset.
источник

AM

Aleks Mayer in SPb Reliability Meetup
Serg Martynov
1. Продуктовая команда и команда инфраструктуры - это разные команды.
2. Мы говорим о разрабах уровня  мидла и выше. Хорошие мидлы всегда знают среду, где запущено их приложение. И они уже знакомы с инфраструктурой. И со звонками в 3 часа ночи, когда бедная ТП не может разобраться, почему сервис лежит)))
Тут есть одно важное допущение. Если инфра на которой запускается приложение вам не принадлежит, дев не будет париться. На стейдже работает, к заказщику отгрузились, дальше "у меня всё работает".
источник

SM

Serg Martynov in SPb Reliability Meetup
Vasiliy Romaneev
Я-то с тобой полностью согласен
разработчик должен быть в курсе как его код работает в реальной жизни.
но не согласен с поинтом, что сисадмин/devops/сре не нужны.
они нужны, как нужны тестировщики, т.к. у них отличный от разрабов mindset.
Вот тут то самое и интересное! Я и  не говорю, что ops-ы не нужны )))
источник

VR

Vasiliy Romaneev in SPb Reliability Meetup
Разве это не твой митап постили в расписании ?)
как умножить на ноль девопса и начать разрабатывать нормально ?)
источник

VR

Vasiliy Romaneev in SPb Reliability Meetup
источник

SM

Serg Martynov in SPb Reliability Meetup
Aleks Mayer
Тут есть одно важное допущение. Если инфра на которой запускается приложение вам не принадлежит, дев не будет париться. На стейдже работает, к заказщику отгрузились, дальше "у меня всё работает".
Да, такой кейс тоже бывает. Но обычно все баги прилетают разрабам и они как раз в курсе, что творится у заказчика, какая там инфрастуктура итд. По крайней мере у тех фирм, которые зарабатывают деньги😂
источник

PR

Paul Rudnitskiy in SPb Reliability Meetup
Интересно, когда выложат записи
источник

AM

Aleks Mayer in SPb Reliability Meetup
Serg Martynov
Да, такой кейс тоже бывает. Но обычно все баги прилетают разрабам и они как раз в курсе, что творится у заказчика, какая там инфрастуктура итд. По крайней мере у тех фирм, которые зарабатывают деньги😂
Угу, и выпускают бесконечные патчи. 😂
источник

VR

Vasiliy Romaneev in SPb Reliability Meetup
Aleks Mayer
Угу, и выпускают бесконечные патчи. 😂
я ж говорю - майндсет другой.
чтобы это отловить до прода и нужны qa и sre
сейчас индустрия пытается это формализовать, чтобы с новыми практиками требовалось меньшее количество сотрудников.
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
Хай. в апереле митап будет ?
источник

АМ

Андрей Мавлянов in SPb Reliability Meetup
Serg Martynov
Это не промывание мозгов. Это то, благодаря чему можно повысить свою компетенцию и заработную плату)) нельзя стать хорошим сеньером, архитектором и CTO без знания всех уровней на которых ведётся разработка и работает продукт.
Человечество сравнительно недавно придумало разделение труда, как способ дать заработать всем. А ты вот щас говоришт что разделение труда это неправильно. Ну во всяком случае это слышится так.
источник

VR

Vasiliy Romaneev in SPb Reliability Meetup
Андрей Мавлянов
Человечество сравнительно недавно придумало разделение труда, как способ дать заработать всем. А ты вот щас говоришт что разделение труда это неправильно. Ну во всяком случае это слышится так.
разделение труда даёт плюсы не тем, что все могут зарабатывать, а тем, что человеку проще набрать квалификацию в одной области.
Сергей прав - если разработчики смогут набрать компетенций, чтобы заместить SRE и QA - они будут больше зарабатывать.
На мой взгляд - многое смогут, но далеко не всё.
источник

W

Womchik in SPb Reliability Meetup
Останутся только разработчики
источник