Но это полная противоположность тому, что нужно в решении технических задач. Хард-скиллы требуют строго обратного:
... - игнорировать мнения и советы от некомпетентных коллег; - действовать смело и решительно.
Игнорировать мнения - вы здесь прям токсичный антипаттерн привели :) Нужно не игнорировать, а наставлять и обучать, чтобы потом самому легче жилось.
Можно сказать, что в современном мире, особенно на удалёнке, коммуникативные навыки должны быть адекватно развиты. И они постепенно переходят в hard-skills, особенно при росте грейда, и особенно при работе в команде.
Нормальная коммуникация сэкономит много времени и сил всех и каждого.
И не стоит забывать, что все люди и все ошибаются. И надменное "да я лучше знаю, да у меня Х лет опыта!" как мысленный ответ джуну может выйти боком. И джуны бывают правы :)
Так что стоит разделить ситуации, когда надо действовать решительно и смело (при тушении пожаров), а когда нужно подумать и по-человечески договориться (при нормальной работе).
В решении технических задач вы никак не сможете договориться с оперативной памятью, чтобы она вместила больше данных, а с процессором на большее количество тактов в секунду. Софт-скиллы вам никак не помогут.
Зачастую, технические задачи переплетены с коммуникацией, если они касаются межкомандного взаимодействия (работа с чужим сервисом, доработка общей библиотеки). И отсутствие софт-скиллов в этом случае совершенно точно не ускорит принятие общих договорённостей ;)
В случае отката всё просто — старая версия сервиса в этот момент ещё жива. Поэтому достаточно переключить трафик обратно на неё и погасить новые поды.
Обновили первый кластер, стали обновлять второй и тут в первом «отвалилась сеть». Ладно, откатываем второй и затем первый. Но как — в первом же «отвалилась сеть»?
Но в этом случае проблемы не будет — первый кластер успешно переключился на новую версию, второй в процессе переключения. И если в первом отвалилась сеть — это уже не повлияет на второй, т.к. первый уже был переключен. Значит, версии в кластерах будут консистентны, и деплой можно не отменять.
А теперь считаем :)
И идём в текст оригинала.
Лучше же привести реальную практическую цифру в оптоволокне - 7.5 мс.
Игнорировать мнения - вы здесь прям токсичный антипаттерн привели :)
Нужно не игнорировать, а наставлять и обучать, чтобы потом самому легче жилось.
Можно сказать, что в современном мире, особенно на удалёнке, коммуникативные навыки должны быть адекватно развиты. И они постепенно переходят в hard-skills, особенно при росте грейда, и особенно при работе в команде.
Нормальная коммуникация сэкономит много времени и сил всех и каждого.
И не стоит забывать, что все люди и все ошибаются. И надменное "да я лучше знаю, да у меня Х лет опыта!" как мысленный ответ джуну может выйти боком.
И джуны бывают правы :)
Так что стоит разделить ситуации, когда надо действовать решительно и смело (при тушении пожаров), а когда нужно подумать и по-человечески договориться (при нормальной работе).
Зачастую, технические задачи переплетены с коммуникацией, если они касаются межкомандного взаимодействия (работа с чужим сервисом, доработка общей библиотеки).
И отсутствие софт-скиллов в этом случае совершенно точно не ускорит принятие общих договорённостей ;)
Но в этом случае проблемы не будет — первый кластер успешно переключился на новую версию, второй в процессе переключения. И если в первом отвалилась сеть — это уже не повлияет на второй, т.к. первый уже был переключен. Значит, версии в кластерах будут консистентны, и деплой можно не отменять.