Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
DevZen Bot
@devzenbot
MobileOptimized. Промокод devzen10
https://twitter.com/moconfdev/status/1309076023548538884
Темы и вопросы слушателей для 0307
https://devzen.ru/themes-0307/
singleplayer88
@singleplayer88
вопрос из чата: а стоит предупреждать кандидата про формат собеседования? о том, что будет теория по го и алгоритмическая задачка
мне кажется, это не совсем ок, час спрашивать про го, а потом раз и давайте разворачивать линкед лист
Nevkontakte
@nevkontakte
стоит
Все, что понижает уровень стресса и запутанности у кандидата, стоит делать :)
Valery Meleshkin
@sumerman
++
singleplayer88
@singleplayer88
уровень 0
Yevgenii Kolakovskiy
@Gtvar_twitter
В подкасте 0306 Роксана просто молодчинка, а вот Александр уводил дисскусию, придирался и просто эпик фейл посредине дисскуса захотел переключить на другую тему. Незачет, очень неприятно слушать Александра.
Pavel Kalashnikov
@kalashnikovisme
Преимущество вечера субботы в одиночестве, что можно послушать прямой эфир DevZen ))
DevZen Bot
@devzenbot
wifi
Aleksander Alekseev
@afiskon
Ivan Glushkov
@gliush
Привет, Паша!
Pavel Kalashnikov
@kalashnikovisme
Привет)))
DevZen Bot
@devzenbot
Интервью с гостем
Pavel Kalashnikov
@kalashnikovisme
Очень важный вопрос: когда примерно гостя перестали называть (или он сам себя перестал называть) сисадмином и стали называть DevOps?
Ivan Glushkov
@gliush
мы вроде уже как-то обсуждали, что такой должности DevOps Eng - вообще нет.
какая-то погоня за хайпом ...
Pavel Kalashnikov
@kalashnikovisme
Здесь не могу ни подтвердить ни опровергнуть, не погружался в эту проблему сильно. Но если вбить в поиске "DevOps вакансии", будут сотни, а может и тысячи записей, где в должности будет стоять DevOps. Так что если ориентироваться на это, должность есть. Но это не значит, безусловно, что это логически правильно.
Ivan Glushkov
@gliush
а кто же тогда ходит на прод?
погоди, тогда наоборот - если ДевОпс, тогда сами программисты ходят на прод
Pavel Kalashnikov
@kalashnikovisme
Ваня по логике прав :)
Но по сути обычно происходит, что есть один чувак, который сам всё настраивает, и все его кличат DevOpsом))
И да "большая компания" здесь важное пояснение. Когда у тебя сотни программистов, дать каждому правильные навыки по работе с продакшеном или инфраструктурой - это сложная история. Легче заиметь ограниченный набор людей, который это делает. Их в больших компаниях обычно называют "девопсами".
Pavel Kalashnikov
@kalashnikovisme
Про "программисты не могут ходить на прод" - моё личное мнение, которое никому не навязываю: программистам нечего делать на проде. Если программистам нужны стейджинги, куча стейджингов, другие окружения, они их должны получить. Программисты на проде должны присутствовать только в виде результата деятельности CI, CD и других систем.
А вот, если я правильно, понимаю, что на такие моменты, нужен SRE. Который должен иметь набор инструкций на случай упавшего прода.
Есть другой вопрос: SRE не знает продукта на уровне кода и фич. Но и тут есть решения свои. Например, управление релизами. Если SRE увидел, что падает новая фича, откатил до релиза, когда фичи не было.
Pavel Kalashnikov
@kalashnikovisme
Про вёрстку писем есть лайфхак :) Приходишь в Mailchimp или другой сервис рассылки: делаешь там себе шаблон, берёшь HTML этого шаблона и используешь у себя :) Да, все изменения нужно будет протестировать уже. Но тестировать небольшие изменения шаблона из популярного сервиса легче, чем самописный шаблон тестировать полностью.

Да, в случае когда надо передернуть сервис по ранбуку, то подойдет. А если проблема связана с нетривиальной проблемой в бизнес-логике (программа работает, но считает не то потому что поставщик данных что-то поменял, например), то привет.

Такое бывает, да. Но если такое происходит в новой фиче, убрал фичу через релизы. Если такая проблема возникла внезапно на старой фиче, значит, эта проблема нечастая (до этого не было же), значит, проблема может подождать до утра. Да, конечно, всё это верно в случае, когда не релизятся в пятницу вечером.

А если клиент вдруг наткнулся на этот случай на старой фиче и этот клиент ООООООООООООООООООООЧЕНЬ важен для компании, можно и программиста разбудить, я думаю. Мегаважных клиентов, которые подождут до утра с проблемами не так часто случаются, так что пережить можно :)
Ivan Glushkov
@gliush
Не, Паш, в сложных системах нет таких простых решений. Часто бывает ситуация, когда у тебя все хорошо, все работает, но появился какой-то новый юзкейс клиентов, и он плохо работает.
Плюс, очень сложно откатывать правильно миграции БД.
Плюс, иногда бывает проблема в связанном сервисе, и неочевидно, в каком.
Что надо откатывать, если ты видишь рост запроса обращений к БД в течение последних трех дней?
Или, скажем, проблема в амазоне, и тебя случайно цепануло.
Короче, куча всего, что тяжело покрыть, если ты не разработчик сервиса.
Ivan Glushkov
@gliush
Сейчас читаю книгу "Chaos Engineering", там прям очень много хороших примеров падений, которые вообще невозможно предсказать, и тяжело разобраться, где реально происходит проблема.
Alexey
@dbf256
о, надо посмотреть книжку :)
Iurii Ogiienko
@ogiyenko_twitter
Наверно это похоже на netlify.
DevZen Bot
@devzenbot
Релокейт курильщика
https://habr.com/ru/post/522524/
Pavel Kalashnikov
@kalashnikovisme

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

Уходил на созвон. Так что приношу извинения, что поздно отвечаю :) Хочу здесь подчеркнуть, что проблемы в таких ситуациях делятся на три категории:

  • не важные и не частые, здесь SRE следит за тем, что проблема не расползается на большое количество пользователей или иных сущностей и ждёт, когда проснётся программист
  • важные, но не частые. Здесь может быть ситуация, что нужен программист, потому что проблемы крайне важные и их нужно решать прямо сейчас. Такой вид проблем бывает реже остальных, поэтому тут чаще можно рассматривать опцию - разбудить программиста.
  • частые и не важные. Такой вид проблем решается либо откатом релиза или может быть отключением сервиса даже, why not. Или можно учитывая, что проблемы не важные, это терпит до утра.

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

А, забыл! Четвёртый вид проблем.
  • частые и важные. Это полная жесть, надо будить всех и решать сразу проблему :) В любом случае, если такое происходит, следует после решения искать первопричины такой ситуации. Моё мнение, что если первые три вида можно иногда допускать в работе продукта, то четвёртый вид ситуации НЕ должны происходить, но естественно, что никто не застрахован.
DevZen Bot
@devzenbot
MobileOptimized. Промокод devzen10
https://twitter.com/moconfdev/status/1309076023548538884
Темы и вопросы слушателей для 0308
https://devzen.ru/themes-0308/
Pavel Kalashnikov
@kalashnikovisme

Тема реально хайповая про фреймворки.

У меня принципиальная позиция по этому вопросу есть: каждая из групп имеет верные позиции в своих рассуждениях.

Pavel Kalashnikov
@kalashnikovisme
"Здравствуйте, меня зовут #{username}. И я DevOps"
А, название же два слова должно быть))
singleplayer88
@singleplayer88
Боты уже все записали да да
Ivan Glushkov
@gliush
ааа, опасно, нас записали!
DevZen Bot
@devzenbot
Интервью с Гостем