Код можно посмотреть при онлайн кодинге при собесе. Обычно стиль кода в разных конторах разный. На основании отличающего стиля любят делать неправильные выводы. А ведь человек готов был подстроиться под правила вашей команды. На тестовое задание вы были готовы ответить тестовой зарплатой?
Метрики железа и окружения лучше вообще разделить от метрик самописной части. Только так будет видна полная картина. Но при микросервисной архитектуре без трейсинга часто метрики бесполезны.
Вы правы, что наблюдаемость, это метрики, логи, tracing, но кто кроме разработчика напишет loging во всех местах debug, в критических info и error? Кто кроме разработчика сформирует нужные метрики и даст возможность их забирать по пробам? Кто кроме разработчика отправит в коллектор сигналы tracing'а? Разработчикам просто нужно больше учиться, а не валить все на зону ответственности ops. Это же касается и дебага, поиска текущей памяти и т.п.
Если парсищие не наглеют, пусть себе парсят, да и не заметны они особо при таком небольшом трафике. А вот если наглеют и сильно грузят систему, сомнительная выгода бизнесу (распознаются и получают левые данные). Списки IP всяких поисковых систем доступны, и по желанию SEO добавляются в белый лист.
Всегда интересно, за счет чего в облаках: "Общий метамотив — это экономия: времени, ресурсов, денег."? При сильно рваной нагрузке наверно да, если правильно отработает автомаштабирование. При стартапе, когда непонятно что будет завтра, и нет пока смысла покупать свои сервера, облако дороже, но выбора нет. А вот в остальных случаях как насчитали выгоду и дешевизну?
Все меньше, к сожалению, людей со знаниями сисадминов, и все больше писателей yaml. Но есть и плюсы, всегда найдется работа. Знание asm, c, c++ очень полезно для понимания, что как работает, как выглядит нагрузка чего и т.п. Для сисадмина это очень полезно. Спасибо за хорошую статью!
Умение смотреть трафик в wireshark, это не совсем то чем занимается сетевой инженер. Вот там всякие железки L2-L3, всякие маршрутизации, vlanы и т.д. (кучи протоколов, особенностей, облачных реализаций и т.п.) врятли снились даже синьору dev, да и зачем? Что для devops, так это сетевое взаимодействие, сетевые распределенные fs, и т.п. Синьор dev много знает про работу например Ceph, и почему из нее плохо читать чанками? В том то и дело...
Поражает ширина умений некоего мифичкеского "devops инженера". Теперь: "DevOps инженеру необходимо разбираться в сетях не хуже специализированного нетворк инженера". Остается добавить умение играть на скрипке, приуспеть в паурлифтинге, да и в боксе было бы неплохо. Что еще придумают авторы курсов? :)
С джуниорами все нормально, так же как и с мидлами и с сеньорами. А вот с войтишниками не очень. IT наукоемкая отрасль, но инфоцигане (продавцы курсов) уверяют что можно получить серьезное образование не за 5 лет, а за 3 месяца. Результатом такого "образования" становится не джун, а вайтишник, с логичными проблемами с трудоустройством.
Вот это: "вы не хотите тратить человеческий ресурс на администрирование инфраструктуры" и наличие K8S это противоположенные установки. Вы серьезно считаете что Kubernetes не нуждается в ресурсе на администрирование?
Вместо того чтоб проверить подходят ли умения и мотивация человека под реальные задачи на месте куда он устраивается на работу, начинаются пожелания посещения хакатонов, выкладки в git, и т.п. То нелепые тестовые задания на скоростную сортировку, для сотрудника который потом неспешно кидается json'ами по rest'у. То тест на принципы ООП и архитектуры, для фронта что кнопочки рисует. Цирк с конями продолжается...
Синьера от джуна отличает умение выбрать нужное количество слоев-абстракций, золотую средину межде хардкодом и софткодом, количеством зацеплений-зависимостей и т.п. исходя из задачь бизнеса. Задача бизнеса вывести "Hello world", используем паттерн скрипт, ни каких процедур. :) Хороший язык это позволяет.
Код можно посмотреть при онлайн кодинге при собесе. Обычно стиль кода в разных конторах разный. На основании отличающего стиля любят делать неправильные выводы. А ведь человек готов был подстроиться под правила вашей команды. На тестовое задание вы были готовы ответить тестовой зарплатой?
И GS был? А у меня Profi 1024, cdos modem, два флопа 5.25, монитор Кодис М. Еще программатор по CP/M.
Метрики железа и окружения лучше вообще разделить от метрик самописной части. Только так будет видна полная картина. Но при микросервисной архитектуре без трейсинга часто метрики бесполезны.
Вы правы, что наблюдаемость, это метрики, логи, tracing, но кто кроме разработчика напишет loging во всех местах debug, в критических info и error? Кто кроме разработчика сформирует нужные метрики и даст возможность их забирать по пробам? Кто кроме разработчика отправит в коллектор сигналы tracing'а? Разработчикам просто нужно больше учиться, а не валить все на зону ответственности ops. Это же касается и дебага, поиска текущей памяти и т.п.
Продавцы курсов, не нравится когда о ваших поделках говорят правду? За это сливаете карму, этим только доказывая ваш обман наивных людей.
Компании покупающие рекламу сливают карму, чтоб мешать комментирующим раскрывать обман.
Если парсищие не наглеют, пусть себе парсят, да и не заметны они особо при таком небольшом трафике. А вот если наглеют и сильно грузят систему, сомнительная выгода бизнесу (распознаются и получают левые данные). Списки IP всяких поисковых систем доступны, и по желанию SEO добавляются в белый лист.
Зачем текстовый вывод графикой?
Всегда интересно, за счет чего в облаках: "Общий метамотив — это экономия: времени, ресурсов, денег."? При сильно рваной нагрузке наверно да, если правильно отработает автомаштабирование. При стартапе, когда непонятно что будет завтра, и нет пока смысла покупать свои сервера, облако дороже, но выбора нет. А вот в остальных случаях как насчитали выгоду и дешевизну?
А если ветер с низу?
Все меньше, к сожалению, людей со знаниями сисадминов, и все больше писателей yaml. Но есть и плюсы, всегда найдется работа. Знание asm, c, c++ очень полезно для понимания, что как работает, как выглядит нагрузка чего и т.п. Для сисадмина это очень полезно. Спасибо за хорошую статью!
Умение смотреть трафик в wireshark, это не совсем то чем занимается сетевой инженер. Вот там всякие железки L2-L3, всякие маршрутизации, vlanы и т.д. (кучи протоколов, особенностей, облачных реализаций и т.п.) врятли снились даже синьору dev, да и зачем? Что для devops, так это сетевое взаимодействие, сетевые распределенные fs, и т.п. Синьор dev много знает про работу например Ceph, и почему из нее плохо читать чанками? В том то и дело...
Серьезно думаете что умения сетевого инженера со знанием сетевой безопасности, это запуск tcpdump-tshark?
Поражает ширина умений некоего мифичкеского "devops инженера". Теперь: "DevOps инженеру необходимо разбираться в сетях не хуже специализированного нетворк инженера". Остается добавить умение играть на скрипке, приуспеть в паурлифтинге, да и в боксе было бы неплохо. Что еще придумают авторы курсов? :)
С джуниорами все нормально, так же как и с мидлами и с сеньорами. А вот с войтишниками не очень. IT наукоемкая отрасль, но инфоцигане (продавцы курсов) уверяют что можно получить серьезное образование не за 5 лет, а за 3 месяца. Результатом такого "образования" становится не джун, а вайтишник, с логичными проблемами с трудоустройством.
Автор где-то видел "крутого" DBAшника "бородатого", который не любит учится? А "крутым" он стал нечайно?
Вот это: "вы не хотите тратить человеческий ресурс на администрирование инфраструктуры" и наличие K8S это противоположенные установки. Вы серьезно считаете что Kubernetes не нуждается в ресурсе на администрирование?
Вместо того чтоб проверить подходят ли умения и мотивация человека под реальные задачи на месте куда он устраивается на работу, начинаются пожелания посещения хакатонов, выкладки в git, и т.п. То нелепые тестовые задания на скоростную сортировку, для сотрудника который потом неспешно кидается json'ами по rest'у. То тест на принципы ООП и архитектуры, для фронта что кнопочки рисует. Цирк с конями продолжается...
Синьера от джуна отличает умение выбрать нужное количество слоев-абстракций, золотую средину межде хардкодом и софткодом, количеством зацеплений-зависимостей и т.п. исходя из задачь бизнеса. Задача бизнеса вывести "Hello world", используем паттерн скрипт, ни каких процедур. :) Хороший язык это позволяет.
�
Для "Hello world!" не обязательно уточнять точку входа, и даже создавать функцию (не говоря уже про класс с методом). :)