Pull to refresh

Comments 13

От одного только ТЗ уже можно прийти в восторг :-) Спасибо за статью!

Спасибо огромное команде, было интересно 😁

Ещё хотел добавить, что некоторые участники просто запретили всю сетевую активность для bingo на нодах кроме бд и балансера и прошли slow start хоть и без секретного кода

Спасибо за положительную обратную связь. Очень приятно осознавать, что твой труд нанёс людям добро.
Что касается slow start, то в отчётах участники принесли несколько разных способов обнаружения возможности его пофиксить. Самым распространённым способом было найти код в бинарнике и из текста понять, что нужно предпринимать какие-то действия в этом направлении. Этот факт мы обязательно учтём в будущих мероприятиях.
Описанный Вами способ решить проблему slow start вполне хорош. Здесь нужно обязательно учесть, что запрещать исходящий трафик можно по-разному. В конечном счете для решения slow start не имеет значения, заблокирован только трафик до нужного хоста по нужному порту или вообще весь исходящий. Имеет значение только как он заблокирован. Если по итогу запрос завершается быстро, то slow start починен и код в консоль будет выведен.

А вот такое видение получилось от самого участника тренировок 😉

https://github.com/d3adwolf/young-yandex-devops

Не осилил только прикол с блокировкой гугла. Петина зеленая галочка про быстрый старт не направила копать задержку, а режил просто собрав контейнеры на базе алпайна.

По активным хелсчекам для нджинкса есть модуль https://github.com/yaoweibin/nginx_upstream_check_module, правда пришлось собирать нджинкс с поддержкой этого модуля, но задачу свою он прекрасно решает.

Да, есть сторонние модули с активными хэлсчеками для nginx. У Вас в решении получился хороший docker образ nginx с этим модулем. Кроме того, есть возможность получить активные хэлсчеки при помощи lua. Это рабочие решения. Но с учетом того, что отрывок про nginx писался в первую очередь для тех, кто не переопределил proxy_next_upstream, я не стал эти варианты в него включать.

Понимаю, что это учебная задача, но в настоящей конторе она решает по-другому: создаётся тикет с запросом руководства оператора и прочей необходимой технической документации, затем забивается болт на эту задачу до решения тикета.

И как у вас получилась stateless база данных?

А, ну это же яндекс, тогда понятно. Кластер прошёл тест по памяти? Сложность контейнеров посчитали?

но в настоящей конторе она решает по-другому: создаётся тикет с запросом руководства оператора и прочей необходимой технической документации, затем забивается болт на эту задачу до решения тикета.

Хорошо вам там, в идеальном мире? И в белом плаще.

"Сегодня я разберу финальное задание, как и обещал участникам тренировок. Оно состоит в том, чтобы развернуть инсталляцию приложения из готового бинарника, которая будет соответствовать SLA из ТЗ"

оно состоит в том чтобы "пойти туда - не знаю куда, принести то - не знаю что", господи я так только древнее легаси от ibm запускал. в нормальном варианте вроде должна быть документация ко всему этому хозяйству.

над вычиткой логов в попытках найти порты посмеялся, netstat же нам не нужен.

в общем создаем себе трудности чтобы активно их преодолевать - тогда так и пишите в описании, а то я оставил статью на десерт, а послевкусие как от сахарозаменителя...

если бинарь был не стрипованный, то strings не показал бы всю нужную информацию?

Строки с кодами плэйн текстом в stripped бинарнике никуда бы не делись.

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

Подскажите, какое значение Time-to-market у вашего решения? Это наверная одна из главных метрик, которая позволяет оценить качество внедрения DevOps. Насколько понимаю, в приведённом примере эта величена огромная. Выдали вам бинарь, выдали ТЗ на развёртывание, а дальше уже сами. Такие коты в мешке явление не новое, явление знакомое, проходил на своём опыте, уверен, не только я. Такое явление говорит о том что такая ценность DevOps методологии как Sharing (умение работать в команде и разговаривать друг с другом) находится в зачаточном состоянии.

В статье немного коснулись ценности Measurement (сбор и анализ данных, чтобы на их основе улучшать процессы), когда писали о fluentd. Только почему дело ограничилось только самим приложением? База данных тоже пишет логи и иногда они могут многое подсказать. С другой стороны, что ваше приложение отдаёт по запросу /metrics?

Что по вашему в приведённой задаче нужно, а что можно автоматизировать (Automation)? Автоматизация всего что можно одна из основных ценностей методологии DevOps. К сожалению, иногда даже доходит до абсурда, когда решают, что DevOps это только про автоматизацию (админ, который всё автоматизирует).

Ещё раз спасибо, за хороших материал.

Sign up to leave a comment.