А точно сокращение скорости выкатки релизов хорошая идея?
Приветствую. У меня встречный вопрос: а чего бы этой идее быть плохой? Теперь постараюсь развернуть, как это выглядит у нас. Как указано в статье, именно "следование рекомендациям позволило сократить скорость выкатки релизов". То есть: мы не урезаем какие-то этапы жизненного цикла задачи, мы не отдаем на откуп командам голые факты по типу "Кажется, у тебя тут проблема. Как хочешь, так ее и решай" и тд. Как только замечаем аномалию, первым делом исследуем вопрос. После того, как мы подтвердили какую-то гипотезу, мы отдаем команде готовую рекомендацию, которая включает в себя либо лучшие практики внутри компании, либо аналогичные решения проблем на основе рыночных решений, либо, если такого не нашлось или нам не подойдет, делаем свой подход, которой способен данную задачу решить. А следование этим рекомендациям само по себе дает такой эффект. У нас есть аналогичные кейсы, когда мы чинили процесс на ранних этапах, а по итогу получали на его фоне еще и прирост к скорости доставки фич на 2/3, помимо выправления фокусного аспекта. Резюмируя: мы улучшаем процессы органично, не гонясь за формальными показателями, а добиваясь реальных улучшений.
Таким образом, canary становится достаточно дорогим удовольствием
Это потому что, если я верно понял, речь не о кенари, как таковом, а о "дублях" по сути реплик прода, если я верно понял аспекты вашей архитектуры, то используется что-то вроде липких сессий, которые гоняют трафик на нужный инстанс.
Возможно, существуют решения, которые в этом способны помочь. Например, у нас схожая архитектура, и я приглядел полноценный кенари вариант с Argo Rollouts (не смотрел, можно ли ссылки, поэтому без них). Но его только собираемся внедрять.
staging окружение не способно отловить проблемы больших нагруженных проектов
Здесь подразумевается, что на больших данных непредсказуемо поведение, потому что стейдж != прод по количеству и качеству данных, или что именно сам фактор нагрузки может повлиять (например, лавинообразный рост трафика)?
Rollback — это ручной откат до предыдущей версии сервиса.
Можно и не на предыдущую. После того, как в моей практике был случай, что решили править хотфиксом, а он не помог/сломал сильнее, а откатиться можно было только на предыдущую версию, то там для нас роллбэк готовил два стула, а точнее один, но с эффектами обоих.
После этого я переписал пайплайны выкатки так, чтобы количество ревизий было 10(на всякий случай, но можно и 5). Есть/пить они не просят, а вот откатиться после неудачных хотфиксов можно было далеко назад.
Ну и переписал пайплайны на роллбэк так, чтобы можно было выбрать на сколько ревизий откатиться. По умолчанию можно жать на кнопку, и он стандартно откатит на предыдущую ревизию.
По окружениям: если со stage все понятно (крутятся e2e, интеграционные тесты), то на этапе чтения про
beta, stable и foreign
Возник вопрос, а, может, canary закроет потребности? Так и canary на месте. Не выходит ли это слишком дорого? Почему canary в данном случае не может закрыть вопрос 3х предыдущих окружений?
Коллекции postman можно гонять автоматически через newman, в свою очередь все это флоу можно положить в ci. Что в таком случае блочит 20 инженеров с релизами каждый день?
Даже если не брать во внимание kubectx, то переключение между конфигами можно забить в алиасы. Я пользовался и тем, и другим. Не вижу, чтобы было дольше создать конфиг руками, закинуть в алиас контекст и вызывать нужный лёгким движением руки.
Да, список не под рукой, но у меня блок алиасов для k8s в .bashrc вынесен отдельно, поэтому grep'ом удобно посмотреть. (При желании и это тоже можно запихать в алиас, некоторые коллеги так и делают).
Нет, никаких негативных аспектов из вышеописанного. На чеке ИПР всегда можно сказать, что ты успеваешь, а что нет. Так же как и при обсуждении ИПР можно сказать, что бы ты не хотел делать из предлагаемого.
Про время. Естественно, в рабочее время. Нет практики обязывать делать что-либо вне рабочего времени.
Плюсую (пока мысленно) за AnyDesk. Несколько лет назад перешли на него из-за уже не помню какой необходимости. Так вот, с задачами справляется на ура. Причем мы ОЧЕНЬ много работали с удалённым машинами. Не встречал кейсов, при которых бы нам не хватило бесплатного AnyDesk
Он не хочет или не способен прояснить критичные для себя моменты на этапе собеса.
У меня, например, существует свой чек-лист с интересующими меня вопросами к компании. И однажды я попал в компанию, стаж в которой у меня составил 1,5 месяца. А все потому, что мне банально врали, отвечая на мои вопросы во время собеседования, хотя я изначально обозначил, что испрашиваемые критерии - критичны. Естественно, аспект за аспектом раскрылись во время работы.
Что касается дальнейшего устройства: проблем с поиском не испытал от слова совсем - было достаточно предложений просто по открытой вакансии, никому резюме не отправлял. И вот следующим местом работы доволен "как кот".
P.S. тотально на всех собесах меня спрашивали только а ля "расскажите про опыт работы", но никто даже завуалировано не спросил "а почему там 1,5 месяца".
Приветствую.
У меня встречный вопрос: а чего бы этой идее быть плохой?
Теперь постараюсь развернуть, как это выглядит у нас. Как указано в статье, именно "следование рекомендациям позволило сократить скорость выкатки релизов". То есть: мы не урезаем какие-то этапы жизненного цикла задачи, мы не отдаем на откуп командам голые факты по типу "Кажется, у тебя тут проблема. Как хочешь, так ее и решай" и тд. Как только замечаем аномалию, первым делом исследуем вопрос. После того, как мы подтвердили какую-то гипотезу, мы отдаем команде готовую рекомендацию, которая включает в себя либо лучшие практики внутри компании, либо аналогичные решения проблем на основе рыночных решений, либо, если такого не нашлось или нам не подойдет, делаем свой подход, которой способен данную задачу решить.
А следование этим рекомендациям само по себе дает такой эффект. У нас есть аналогичные кейсы, когда мы чинили процесс на ранних этапах, а по итогу получали на его фоне еще и прирост к скорости доставки фич на 2/3, помимо выправления фокусного аспекта. Резюмируя: мы улучшаем процессы органично, не гонясь за формальными показателями, а добиваясь реальных улучшений.
Используйте newman. Не припомню, чтобы там были ограничения.
Можете загнать, например, в gha и пусть он по расписанию вам крутит
Это потому что, если я верно понял, речь не о кенари, как таковом, а о "дублях" по сути реплик прода, если я верно понял аспекты вашей архитектуры, то используется что-то вроде липких сессий, которые гоняют трафик на нужный инстанс.
Возможно, существуют решения, которые в этом способны помочь. Например, у нас схожая архитектура, и я приглядел полноценный кенари вариант с Argo Rollouts (не смотрел, можно ли ссылки, поэтому без них). Но его только собираемся внедрять.
Здесь подразумевается, что на больших данных непредсказуемо поведение, потому что стейдж != прод по количеству и качеству данных, или что именно сам фактор нагрузки может повлиять (например, лавинообразный рост трафика)?
Спасибо за ответ!
Здравствуйте.
Можно и не на предыдущую. После того, как в моей практике был случай, что решили править хотфиксом, а он не помог/сломал сильнее, а откатиться можно было только на предыдущую версию, то там для нас роллбэк готовил два стула, а точнее один, но с эффектами обоих.
После этого я переписал пайплайны выкатки так, чтобы количество ревизий было 10(на всякий случай, но можно и 5). Есть/пить они не просят, а вот откатиться после неудачных хотфиксов можно было далеко назад.
Ну и переписал пайплайны на роллбэк так, чтобы можно было выбрать на сколько ревизий откатиться. По умолчанию можно жать на кнопку, и он стандартно откатит на предыдущую ревизию.
По окружениям: если со stage все понятно (крутятся e2e, интеграционные тесты), то на этапе чтения про
Возник вопрос, а, может, canary закроет потребности? Так и canary на месте. Не выходит ли это слишком дорого? Почему canary в данном случае не может закрыть вопрос 3х предыдущих окружений?
Не совсем понял смысл написанного, так как сам уж сколько лет юзаю wsl и проблем с tsh или lens не испытываю от слова совсем.
И на секундочку это все писал
Ну или, возможно, в будущем люди придумают удаленку, и никуда не надо будет переезжать.
Простите, что?
Это потому что у вас хорошего деврела не было. Или не было совсем, а не только хорошего
Коллекции postman можно гонять автоматически через newman, в свою очередь все это флоу можно положить в ci. Что в таком случае блочит 20 инженеров с релизами каждый день?
И чем это быстрее/лучше/проще edit deployment?
cron
Не знаю, не ко мне вопрос.
А что мешает юзать vs code в обычном терминале?
Даже если не брать во внимание kubectx, то переключение между конфигами можно забить в алиасы. Я пользовался и тем, и другим. Не вижу, чтобы было дольше создать конфиг руками, закинуть в алиас контекст и вызывать нужный лёгким движением руки.
Да, список не под рукой, но у меня блок алиасов для k8s в .bashrc вынесен отдельно, поэтому grep'ом удобно посмотреть. (При желании и это тоже можно запихать в алиас, некоторые коллеги так и делают).
В голове у очередного работодателя, может, и качнулась)
Нет, никаких негативных аспектов из вышеописанного. На чеке ИПР всегда можно сказать, что ты успеваешь, а что нет. Так же как и при обсуждении ИПР можно сказать, что бы ты не хотел делать из предлагаемого.
Про время. Естественно, в рабочее время. Нет практики обязывать делать что-либо вне рабочего времени.
Плюсую (пока мысленно) за AnyDesk. Несколько лет назад перешли на него из-за уже не помню какой необходимости. Так вот, с задачами справляется на ура. Причем мы ОЧЕНЬ много работали с удалённым машинами. Не встречал кейсов, при которых бы нам не хватило бесплатного AnyDesk
Кстати, годный совет
У меня, например, существует свой чек-лист с интересующими меня вопросами к компании. И однажды я попал в компанию, стаж в которой у меня составил 1,5 месяца. А все потому, что мне банально врали, отвечая на мои вопросы во время собеседования, хотя я изначально обозначил, что испрашиваемые критерии - критичны. Естественно, аспект за аспектом раскрылись во время работы.
Что касается дальнейшего устройства: проблем с поиском не испытал от слова совсем - было достаточно предложений просто по открытой вакансии, никому резюме не отправлял. И вот следующим местом работы доволен "как кот".
P.S. тотально на всех собесах меня спрашивали только а ля "расскажите про опыт работы", но никто даже завуалировано не спросил "а почему там 1,5 месяца".