Занимательная статья, искусственный интеллект в том виде в котором его показывают в фантастических фильмах, еще не существует, есть набор сложных алгоритмов и подходов, делающих наши приложения и сервисы, интеллектуальными для пользователей.
нужная практика, postmortem и runbooks позовяют еще «серчить» по внутреннему confluence проекта в случае проблем (про это в принципе упоминалось в статье), получается очень удобно. Да и как правило проблемы на проекте одинаковые и если все инциденты и проблемы трекать, то легко передавать на саппорт новым инженерам.
Так прямо не ответить, что это за квалификация, мало контекста. Если человек запустил EKS, написал сначала кучу манифестов а потом «завернул» сложное приложение в HELM и все работает то это позитивный сценарий. Да он не знает компоненты k8s, но это и хорошо, например если на проекте куча инструментов то он спасет себя от перегрузки информацией.
О да, проклятие «вечного джуна/мидла» существует, например когда на проекте «сапортишь» чужой код, и не пишешь свой. Так же и с процессами, проект может не дать видимости. Про «необходимость понимания процессов под капотом для уровня advanced и expert» уточните пожалуйста, не очень понял вопрос…
оригинал книги «Делай как в Google. Разработка программного обеспечения» отличный, подойдет для всех кому приходится «управлять» инженерами, интересно посмотреть как получится в переводе.
P.S интересно тоже будет просмотреть «Безопасность контейнеров. Фундаментальный подход к защите контейнеризированных приложений» Лиз Райс достаточно крутая в отрасли.
Хорошая статья, понравилось сравнение с другими BD и когда использовать/не использовать! Картиночки огонь вообще, а в чем картинки делали если не секрет?
Хорошее сравнение производительности Linkerd и Istio, возможно немного нечестное из-за архитектур продуктов, но для конечного «заказчика» важно! Спасибо за перевод, отдельное спасибо за ссылку на инструкции по бенчмаркингу.
Хорошо собрали в одну статью, спасибо. Немного не хватает конкретики по действиям, понимаю, что не планировали, ну типа пошагово, как внедрять безопасность встраиваемых систем Linux.
может я не уловил из статьи (статья занятная), но мне не очень понятно, когда возникает потребность разрабатывать собственную криптографию, немного как-то безумно звучит.
kotosha нужная статья, спасибо. Я думаю, что тут еще может помочь тим лид, заказчик или «руководитель», вовремя предоставляя обратную связь. Чаще всего коммуницируют только когда все плохо. Если своевременно работать со всеми видами обратной связи: позитивная, негативная, конструктивная, развивающая, регулярная, безопасная, то инженер будет чувствовать себя на своем месте.
Все сертификаты и курсы рано или поздно обновляются, гнаться ли за экзаменом когда до обновления остался месяц — это вопрос да, зависит от обстоятельств.
Спасибо за комментарий, рисунок действительно был не актуальный, залил обновленный. Это статья про опыт, а не про рекламу, жаль, что формируется такое впечатление.
Актуальненька, надо попробовать!
Занимательная статья, искусственный интеллект в том виде в котором его показывают в фантастических фильмах, еще не существует, есть набор сложных алгоритмов и подходов, делающих наши приложения и сервисы, интеллектуальными для пользователей.
Можно еще смотреть популярные тулы типа ansible (https://github.com/ansible/ansible) или sentry (https://github.com/getsentry/sentry), почитать коммиты, или посмотреть из каких "компонент" состоят. Не имеет отношение к стандартной библиотеке, но тоже полезно.
P.S интересно тоже будет просмотреть «Безопасность контейнеров. Фундаментальный подход к защите контейнеризированных приложений» Лиз Райс достаточно крутая в отрасли.