Site Reliability Engineering
https://landing.google.com/sre/images/book.png
Масленников Дмитрий пишет, что в Google инженеры хвалятся, кто больше и серьезнее "оутаджи" допустил. Для них важны не понты и перечисление технологии. Ты им покажи свои "постмортемы" и какие выводы ты из них сделал и тогда будет серьёзный разговор :)
Заметьте, что в Гугл много оутаджей в год, но о них почти не слышно. Там наработан огромный опыт и особая культура, как быть с оутаджами. На практике - очень эффективно все работает.
Друзья и коллеги Димы написали даже книгу про это - Site Reliability Engineering.
https://landing.google.com/sre/book.html
https://landing.google.com/sre/images/book.png
Масленников Дмитрий пишет, что в Google инженеры хвалятся, кто больше и серьезнее "оутаджи" допустил. Для них важны не понты и перечисление технологии. Ты им покажи свои "постмортемы" и какие выводы ты из них сделал и тогда будет серьёзный разговор :)
Заметьте, что в Гугл много оутаджей в год, но о них почти не слышно. Там наработан огромный опыт и особая культура, как быть с оутаджами. На практике - очень эффективно все работает.
Друзья и коллеги Димы написали даже книгу про это - Site Reliability Engineering.
https://landing.google.com/sre/book.html
Денис Габайдулин прислал истори, как в далёком 2013м у одноклассников легли все сервера из-за двух переносов строк
https://habr.com/company/odnoklassniki/blog/268413/
Однажды вечером система мониторинга зафиксировала незначительную проблему с одним из серверов.
... [тут описание дальнейших танцев] ...
Нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.
Приходилось восстанавливать бэкапы, внося в них накопившиеся логи транзакций, чтобы затем развернуть рабочие копии и запустить сервисы.
Восстановление первичной работоспособности, когда портал стал хотя бы загружаться и заработала часть функционала, заняло около суток.
Авария произошла в четверг вечером, а в воскресенье утром полностью восстановилась работа портала.
https://habr.com/company/odnoklassniki/blog/268413/
Однажды вечером система мониторинга зафиксировала незначительную проблему с одним из серверов.
... [тут описание дальнейших танцев] ...
Нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.
Приходилось восстанавливать бэкапы, внося в них накопившиеся логи транзакций, чтобы затем развернуть рабочие копии и запустить сервисы.
Восстановление первичной работоспособности, когда портал стал хотя бы загружаться и заработала часть функционала, заняло около суток.
Авария произошла в четверг вечером, а в воскресенье утром полностью восстановилась работа портала.
Хабр
Три дня, которые потрясли нас в 2013
«Если у вас есть сомнения, авария это или нет — то это авария!» (с) Мудрость предков Большие сбои в онлайн-проектах происходят редко. А в больших проектах —...
Додо-пицца открывает новый формат вакансий. Что интересно, реально внедрили TDD и парную разработку :)
https://www.youtube.com/watch?v=esva_8RNSuM
https://www.youtube.com/watch?v=esva_8RNSuM
YouTube
Вакансия в IT команду «Додо Пиццы»
Если ты разработчик, тестировщик, инженер информационных систем, то пиши Виталию Калинину, v.kalinin@dodopizza.com
Сотрудникики IT команды Додо рассказывают изнутри, как устроена разработка в компании.
Больше информации о разработке в Додо на сайте dodois.com…
Сотрудникики IT команды Додо рассказывают изнутри, как устроена разработка в компании.
Больше информации о разработке в Додо на сайте dodois.com…
Парная разработка и TDD - это то, что есть в вашей команде?
anonymous poll
Дорого и времени нет – 25
👍👍👍👍👍👍👍 49%
Иногда что-то делаем такое во время брейн-штоминга – 14
👍👍👍👍 27%
А вы почему интересуетесь? – 11
👍👍👍 22%
Да, в полный рост – 1
▫️ 2%
👥 51 people voted so far.
anonymous poll
Дорого и времени нет – 25
👍👍👍👍👍👍👍 49%
Иногда что-то делаем такое во время брейн-штоминга – 14
👍👍👍👍 27%
А вы почему интересуетесь? – 11
👍👍👍 22%
Да, в полный рост – 1
▫️ 2%
👥 51 people voted so far.
@romajke Алексеев Роман пишет про парное программирование:
При работе над некоторыми задачами можно выделить этап прототипирования решения: пишутся простые тесты, выделяются интерфейсы, общая архитектура решения.
Удобно эту часть работы проводить в паре, а затем распараллеливать работу - один реализует, например, доступ к данным, другой - конфигурацию и интерфейс сервиса.
При работе над некоторыми задачами можно выделить этап прототипирования решения: пишутся простые тесты, выделяются интерфейсы, общая архитектура решения.
Удобно эту часть работы проводить в паре, а затем распараллеливать работу - один реализует, например, доступ к данным, другой - конфигурацию и интерфейс сервиса.
Пары успевают в 1.5-2 раза больше задач. @sbase проверял. Единственная проблема - эмоционально напряжёнее, поэтому нужно делать сессиями,
fb.com/yaroslav.maxymovych Ярослав Максимович пишет про программистов в белых халатах
Сначала известная цитата одного неизвестного программиста: ...я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами.
И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл.
Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков.
Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты.
Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь.
Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики...
* * *
Вторую часть иллюстрации мне, лет десять назад, рассказывали одни потенциальные покупатели старого интернет-аукциона, когда мы обсуждали технические вопросы, поскольку у нас к тому времени уже было 200 тыс пользователей и десять программистов.
История раннего Ebay:
Первая версия их сайта была смешной, слепленной на коленке. Но внезапно к ним полезли регистрироваться тысячи юзеров ежедневно.
Просто их сайт хорошо и вовремя попал в боль рынка.
И постоянно оч быстро росли.
А сервера стабильно оказывались не готовы к все возростающей нагрузке.
Постоянно добирали программистов, вводили новые функции, неважно по какой причине, то ли по требованию пользователей, или безопасности, или срочности, или чего угодно, не важно в общем. Важно лишь что эти функции были нужны.
В результате, на сервере творилось неизвестно что. Какие-то куски кода, разные версии, зависания, глюки. Программисты в белых халатах негодуют. Но главное что бизнес не останавливался, а продолжал отлично расти и приносить деньги на переписку "с нуля".
К какому-то моменту оказалось что в компании из всех программистов был один главный, который из жадности замкнул на себе все процессы, и только он знал как шаманскими танцами с бубном возвращать работоспособность, когда что-то шло не так.
А это совсем не простая работа в условиях стресса, когда у тебя ежедневно миллионы пользователей с миллионами товаров. То есть, каждая минута простоя стоит реальных денег.
В результате парень вымотался, сказал что ему срочно нужен отпуск. Раздал инструкции и пароли сотрудникам.
И умчался в направлении неизвестного отеля на Багамах, выключив телефон.
Спустя какое-то время сервера опять упали.
Оставшиеся программисты не смогли поднять. Спустя сутки, один из инвесторов психанул, взял самолет и помчался на поиски.
Программиста привезли, сервера подняли.
Это был самый большой, полуторасуточный сбой на Ebay.
Сначала известная цитата одного неизвестного программиста: ...я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами.
И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл.
Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков.
Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты.
Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь.
Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики...
* * *
Вторую часть иллюстрации мне, лет десять назад, рассказывали одни потенциальные покупатели старого интернет-аукциона, когда мы обсуждали технические вопросы, поскольку у нас к тому времени уже было 200 тыс пользователей и десять программистов.
История раннего Ebay:
Первая версия их сайта была смешной, слепленной на коленке. Но внезапно к ним полезли регистрироваться тысячи юзеров ежедневно.
Просто их сайт хорошо и вовремя попал в боль рынка.
И постоянно оч быстро росли.
А сервера стабильно оказывались не готовы к все возростающей нагрузке.
Постоянно добирали программистов, вводили новые функции, неважно по какой причине, то ли по требованию пользователей, или безопасности, или срочности, или чего угодно, не важно в общем. Важно лишь что эти функции были нужны.
В результате, на сервере творилось неизвестно что. Какие-то куски кода, разные версии, зависания, глюки. Программисты в белых халатах негодуют. Но главное что бизнес не останавливался, а продолжал отлично расти и приносить деньги на переписку "с нуля".
К какому-то моменту оказалось что в компании из всех программистов был один главный, который из жадности замкнул на себе все процессы, и только он знал как шаманскими танцами с бубном возвращать работоспособность, когда что-то шло не так.
А это совсем не простая работа в условиях стресса, когда у тебя ежедневно миллионы пользователей с миллионами товаров. То есть, каждая минута простоя стоит реальных денег.
В результате парень вымотался, сказал что ему срочно нужен отпуск. Раздал инструкции и пароли сотрудникам.
И умчался в направлении неизвестного отеля на Багамах, выключив телефон.
Спустя какое-то время сервера опять упали.
Оставшиеся программисты не смогли поднять. Спустя сутки, один из инвесторов психанул, взял самолет и помчался на поиски.
Программиста привезли, сервера подняли.
Это был самый большой, полуторасуточный сбой на Ebay.
Yessssssssss!!!!!!!!!!!!!!!!!!!!!! Мы дожили до того момента, когда можно гордиться своим футболом!
Никогда не думал, что в своей жизни такое напишу, но наша сборная сыграла результативнее Аргентины, Германии, Португалии и, это невероятно, Испании.
Более того, оба гола в игре с Испанией залетели от ноги наших футболистов.
Это невероятно.
Это не-ве-ро-ят-но.
Более того, оба гола в игре с Испанией залетели от ноги наших футболистов.
Это невероятно.
Это не-ве-ро-ят-но.
В число неочевидных обязанностей CTO входит жёсткий пуш всей команды для финализации решения на последних метрах дистанции.
Обычная ситуация, когда всё вроде бы по отдельности готово, а вместе не работает. В этом случае требуется аккуратно собрать всё воедино и заставить работать.
Именно тут требуются сила воли и способность концентрировано совершить подвиг. Это вопрос готовности самого CTO победить, когда карманы есть, рукава есть, полы есть, а пиджака ещё нет.
Обычная ситуация, когда всё вроде бы по отдельности готово, а вместе не работает. В этом случае требуется аккуратно собрать всё воедино и заставить работать.
Именно тут требуются сила воли и способность концентрировано совершить подвиг. Это вопрос готовности самого CTO победить, когда карманы есть, рукава есть, полы есть, а пиджака ещё нет.
https://news.1rj.ru/str/temno пишет, что обучение – это вам не то
1. Обучение – это вовсе не последовательная передача новых знаний. Обучение – это последовательное устранение существующих непониманий (misconceptions).
2. Тестирование – это вовсе не инструмент для проверки того, чему ученик научился. Ученик может выбрать правильный ответ по десятку не связанных с правильным пониманием причин. Тестирование – это инструмент для выявления непониманий. Каждый неверный вариант должен соответствовать какому-то из базовых непониманий, которое мы хотим отловить и устранить.
3. Применять этот подход можно не только для обучения. Например, продажи – это не процесс убеждения людей в том, что им нужно купить наш продукт, а поиск и устранение причин – в голове потребителя или в нашем продукте – по которым его не покупают.
1. Обучение – это вовсе не последовательная передача новых знаний. Обучение – это последовательное устранение существующих непониманий (misconceptions).
2. Тестирование – это вовсе не инструмент для проверки того, чему ученик научился. Ученик может выбрать правильный ответ по десятку не связанных с правильным пониманием причин. Тестирование – это инструмент для выявления непониманий. Каждый неверный вариант должен соответствовать какому-то из базовых непониманий, которое мы хотим отловить и устранить.
3. Применять этот подход можно не только для обучения. Например, продажи – это не процесс убеждения людей в том, что им нужно купить наш продукт, а поиск и устранение причин – в голове потребителя или в нашем продукте – по которым его не покупают.
Telegram
Тёмная сторона / Темнографика
Аркадий Морейнис @amoreynis
РКН id=673c96c2340096358bb6492d
РКН id=673c96c2340096358bb6492d
Подражая Морейнису
Мечта - это вовсе не мысли о чем-то прекрасно. Мечта - это то в направлении чего уже движется ваша жизнь.
Мечта - это вовсе не мысли о чем-то прекрасно. Мечта - это то в направлении чего уже движется ваша жизнь.
@maslennikovdm рассказывает про гугловые практики разработки!
Типы ситуаций для вызова внешних экспертов:
Потушить пожар
В IT отделе давно все плохо. Но лиды рапортовали наверх, что все идет по плану. В определенный момент проблем накопилось столько, что произошел взрыв. Учредитель в панике ищет, кто ему поможет.
Эвакуатор
IT отдел все время “косячит”. Срывают сроки релизов. Не могут пофиксить баги или фиксят, но новых появляется больше. Сервис все время падает, не доступен или слишком медленный. Учредителю объясняют это тем, что “так везде” или какими-то неправдоподобными причинами. Он хочет понять правда ли это, так как сам в этом не разбирается.
Предстартовая подготовка
Новая компания или новый проект или новый большой функционал в старом проекте. Учредитель, или даже CTO или лид сомневаются в выборе технологий и архитектурных решений. Нужен аудит архитектуры прежде чем начать проект.
Регулярный техосмотр
Все вроде бы нормально, но хочется лучше. Нужен аудит процессов, практик, кода и архитектуры, чтобы взглянуть свежим незамыленным взглядом и внести новизну в проект.
Потушить пожар
В IT отделе давно все плохо. Но лиды рапортовали наверх, что все идет по плану. В определенный момент проблем накопилось столько, что произошел взрыв. Учредитель в панике ищет, кто ему поможет.
Эвакуатор
IT отдел все время “косячит”. Срывают сроки релизов. Не могут пофиксить баги или фиксят, но новых появляется больше. Сервис все время падает, не доступен или слишком медленный. Учредителю объясняют это тем, что “так везде” или какими-то неправдоподобными причинами. Он хочет понять правда ли это, так как сам в этом не разбирается.
Предстартовая подготовка
Новая компания или новый проект или новый большой функционал в старом проекте. Учредитель, или даже CTO или лид сомневаются в выборе технологий и архитектурных решений. Нужен аудит архитектуры прежде чем начать проект.
Регулярный техосмотр
Все вроде бы нормально, но хочется лучше. Нужен аудит процессов, практик, кода и архитектуры, чтобы взглянуть свежим незамыленным взглядом и внести новизну в проект.
Когда вас вызывать?
public poll
Эвакуатор – 12
👍👍👍👍👍👍👍 33%
Потушить пожар – 8
👍👍👍👍👍 22%
У меня нет времени. Не трогайте меня! – 7
👍👍👍👍 19%
Регулярный техосмотр – 5
👍👍👍 14%
Всегда!!! – 3
👍👍 8%
Предстартовая подготовка – 1
👍 3%
👥 36 people voted so far.
public poll
Эвакуатор – 12
👍👍👍👍👍👍👍 33%
Потушить пожар – 8
👍👍👍👍👍 22%
У меня нет времени. Не трогайте меня! – 7
👍👍👍👍 19%
Регулярный техосмотр – 5
👍👍👍 14%
Всегда!!! – 3
👍👍 8%
Предстартовая подготовка – 1
👍 3%
👥 36 people voted so far.
Волынкин Николай @Nick_Volynkin поднимает в своём канале @docops одну из фундаментальных проблем в современной разработки, актуальную для компаний любого размера, начиная от стартапов и заканчивая многослойными большими корпорациями: как замапить код и его изменения на требования бизнеса.
Например, мы хотим поменять какой-то участок кода. Как найти все требования, которые он реализует? Как спрогнозировать последствия от изменения?
Кажется, что для этого нужно заранее выстраивать цепочку от коммитов к задачи в трекере и к общим документам уровня feature vision или контракта. Просто номера задачи в сообщении коммита не хватает — часто в задаче есть описание только на функциональном уровне, но не рассказано про значение для бизнеса.
Например, мы хотим поменять какой-то участок кода. Как найти все требования, которые он реализует? Как спрогнозировать последствия от изменения?
Кажется, что для этого нужно заранее выстраивать цепочку от коммитов к задачи в трекере и к общим документам уровня feature vision или контракта. Просто номера задачи в сообщении коммита не хватает — часто в задаче есть описание только на функциональном уровне, но не рассказано про значение для бизнеса.
Рекламирую работу @YaviKosh Виктории Кошелевой, трудившуюся над моей скромной персоной упорно и кропотливо, строя настоящего мультяшного персонажа в стикерах для телеги!