Спасибо за ваш отзыв. Я понимаю, что несмотря на доступность списка служебных контейнеров и управления ими в API S3, наш продукт имеет потенциал для дальнейшего развития. Мы обязательно учтем ваше замечание и добавим соответствующую функциональность в нашу Панель Управления в ближайшее время.
Что касается обработки «абортов» и управления оставшимися сегментами. Я уверен, что мы не имеем права самостоятельно, на своей стороне, решать, удалять нам или нет часть вашей информации (даже если она служебная). Дело в том, что со стороны продукта мы никогда достоверно не знаем, как поведет себя ваше ПО: начнет загружать объект снова или вызовет «комплит мультипарт аплоад» и дозагрузит недостающую часть.
Мы изучим логи и внимательно разберем вашу ситуацию. Спасибо, что помогаете нам делать сервис лучше!
Спасибо за интерес к статье! Согласен не очень хорошо сформулировал.
Имел ввиду что Kafka за счет мощной функциональности шардирования по брокерам возможно (но это не точно) переварит больше чем rabbit, несмотря на то что однонодный Rabbit обычно (но не всегда) быстрее чем однонодная Kafka.
Однако в каждом конкретном случае выбор инструмента обычно сложнее, и зависит от специфики проекта и профиля нагрузки на систему.
Если вы решили самостоятельно обслуживать Kafka-кластер в публичной сети, обеспечение безопасности становится вашей работой. Могу дать несколько важных, но, возможно, очевидных для вас рекомендаций:
Убедитесь, что настроена аутентификация для доступа к кластеру Kafka.
Обязательно используйте SSL/TLS для шифрования соединений между клиентами и брокерами Kafka.
Ограничьте доступ к брокерам Kafka только для необходимых вам IP-адресов через брандмауэр.
Регулярно обновляйте версии Kafka и всех связанных компонентов.
Организуйте мониторинг, чтобы следить за активностью кластера, обнаруживать аномалии и подозрительное поведение. Анализируйте журналы для выявления попыток атак.
Список рекомендаций может быть в разы масштабнее. Обеспечение безопасности — серьезная работа, которая редко доступна "из коробки", — ею должны заниматься профессионалы.
Чтобы избежать подобных ситуаций, могу рекомендовать вам в следующий раз использовать готовый сервис от надежных провайдеров облачных услуг.
Спасибо, можно сказать автор вынул из моей головы и структурировал все те мысли что смущали меня когда я сам начал собеседовать и нанимать людей. Вроде простая мысль, но увы не всегда очевидная для начинающих руководителей - "собеседование это не экзамен". Еще раз спасибо в общем.
2) Писать просто, использовать корректные термины, объяснять сложные абстракции иллюстрациями, схемами и примерами;
3) Перед стартом своей работы ознакомиться с тем что уже написано на эту тему;
4) Не забывать что статья должна нести в себе какойто смысл и служить цели. Чего вы хотите чтобы читатель узнал/понял/попробовал после прочтения;
5) Прочитать статью вслух перед публикацией. Так можно определить слабые места, несогласованность окончаний, потерю основной мысли, сюжетной нити и т.д.
Как понял я, в первом случае (все на дедике) вы получаете доступ до объекта который имеет публичный адрес. А на нем находится вся ваша инфраструктура в том числе и БД как на блюдечке! И совсем не факт что он получил доступ к "коду приложения". Он просто получил доступ ко всей файловой системе, этого достаточно. Во втором случае (на дедике только то что нужно), вы получаете доступ только к той части инфраструктуры которой нужно смотреть наружу - например веб-сервер, прокси сервер и тп. Дальше нужно проводить анализ инфраструктуры и продумывать следующие шаги атаки. Это выглядит более трудоемким.
Но да вы правы, при желании взломать можно все что угодно, это всего лишь вопрос времени и ресурсов.
Екатерина, спасибо за годную статью. Возьму ваши примеры на вооружение.
Я как раз сейчас искал чужой опыт проведение ретро на удаленке, но в русскоязычном сегменте интернета это оказалось нетривиальной задачей. В общем спасибо!
Автор модели DISC написал о ней книгу «Emotions of Normal People». Последние издание которой цитируются более чем в 700 научных трудах, если верить Google Academy.
Ну а увлечение комиксами и феминизмом еще никого не делало плохим или непрофессиональным человеком.
Здорово, что у нас у всех есть уникальные способы отличить компетентного человека от некомпетентного 🙂 И спасибо, что поделились своим.
А расскажите, что в биографии автора вас смутило? Также интересно, какие научно обоснованные подходы/инструменты вы используете при выстраивании коммуникаций с коллегами.
Качество общения с коллегой и качество выполнения им задач — объекты весьма разные. Понять это можно, подумав о метриках, которые мы бы использовали для их оценки.
Еще раз соглашусь с вами насчет CJM. Да, он является лучшей практикой для разработки продукта, основывающегося на потребностях пользователей, и это факт.
Но давайте посмотрим на это с другой стороны. Как CJM поможет мне понять:
— Продал ли я свою идею коллеге?
— Хорошо ли коллега меня понял?
— Что вообще важно для моего коллеги? На чем стоит заострить внимание, когда я, например, буду показывать ему тот же CJM покупки с сайта?
— Правильную ли мотивацию я выбрал?
— Не задел ли я случайно его чувств?
— Не повел ли я себя как мудак при разговоре с коллегой?
Иными словами я не предлагаю вам метод персон для развития продукта. Я предлагаю вам модель DISK для ретроспективы и улучшения ваших отношений с людьми. Людьми, с которыми вы проводите большую часть вашей жизни, — вашими коллегами.
Коллега, спасибо большое за интерес к статье. Согласен, что в рамках разработки продукта правильно использовать CJM, а еще JTBD, CustDev, Lean Canvas, HADI и т.д. Но в этом тексте мы рассматриваем инструмент повышения качества общения с коллегами на работе. Кажется, здесь CJM — не помощник.
Спасибо за ваш комментарий, поясню: да, Puppet один из инструментов, который можно использовать в концепции IaC, а можно использовать и вне IaC. Сама же концепция IaC появилась позже, примерно в 2006-2007 вместе с распространением популярности Amazon cloud. Но согласитесь, дата рождения технологии не всегда совпадает с ее распространением в мире? Подробнее можно почитать о кривой проникновения технологии - тут.
Ваш комментарий про AD + GPO и тем более MS Answer file 95 я, увы, не понял. Эти инструменты вообще не про IaC. Часто вы видели чтобы с их помощью создавалсь виртуальная, тонко настроенная инфраструктура, сети, маршрутизация, виртуальные сети, балансировщики? Лично я такого не встречал.
Насчет того почему IaC дополняет DevOps инструменты, и почему это действительно важно можно ознакомится тут.
Я не планировал раскрывать термин DevOps, статья всеже чуть-чуть не об этом. Но спасибо вам, что дополнили и раскрыли этот момент в комментарии.
Спасибо за интерес к продукту! Да, у нас есть живая миграция точки выполнения ВМ с узла на узел. Кроме того, есть живая миграция дисков виртуальных машин из хранилища в хранилище.
Полностью с вами согласен, сотни ВМ обслуживать из интерфейса невозможно. И поэтому у нас есть два инструмента: like REST API со свагером и еще свой провайдер в Terraform. Документация тут. Они позволяют решать задачи управления сотнями и даже тысячами ВМ. Спасибо большое за ваш комментарий!
Спасибо вам за ваш комментарий, возможно я найду силы и время заняться написанием такого сравнения с ProxMox. Мне кажется, что это серьезная работа которую нельзя делать абы как.
Спасибо за ваш отзыв. Я понимаю, что несмотря на доступность списка служебных контейнеров и управления ими в API S3, наш продукт имеет потенциал для дальнейшего развития. Мы обязательно учтем ваше замечание и добавим соответствующую функциональность в нашу Панель Управления в ближайшее время.
Что касается обработки «абортов» и управления оставшимися сегментами. Я уверен, что мы не имеем права самостоятельно, на своей стороне, решать, удалять нам или нет часть вашей информации (даже если она служебная). Дело в том, что со стороны продукта мы никогда достоверно не знаем, как поведет себя ваше ПО: начнет загружать объект снова или вызовет «комплит мультипарт аплоад» и дозагрузит недостающую часть.
Мы изучим логи и внимательно разберем вашу ситуацию. Спасибо, что помогаете нам делать сервис лучше!
Спасибо за интерес к статье! Согласен не очень хорошо сформулировал.
Имел ввиду что Kafka за счет мощной функциональности шардирования по брокерам возможно (но это не точно) переварит больше чем rabbit, несмотря на то что однонодный Rabbit обычно (но не всегда) быстрее чем однонодная Kafka.
Однако в каждом конкретном случае выбор инструмента обычно сложнее, и зависит от специфики проекта и профиля нагрузки на систему.
Если вы решили самостоятельно обслуживать Kafka-кластер в публичной сети, обеспечение безопасности становится вашей работой. Могу дать несколько важных, но, возможно, очевидных для вас рекомендаций:
Убедитесь, что настроена аутентификация для доступа к кластеру Kafka.
Обязательно используйте SSL/TLS для шифрования соединений между клиентами и брокерами Kafka.
Ограничьте доступ к брокерам Kafka только для необходимых вам IP-адресов через брандмауэр.
Регулярно обновляйте версии Kafka и всех связанных компонентов.
Организуйте мониторинг, чтобы следить за активностью кластера, обнаруживать аномалии и подозрительное поведение. Анализируйте журналы для выявления попыток атак.
Список рекомендаций может быть в разы масштабнее. Обеспечение безопасности — серьезная работа, которая редко доступна "из коробки", — ею должны заниматься профессионалы.
Чтобы избежать подобных ситуаций, могу рекомендовать вам в следующий раз использовать готовый сервис от надежных провайдеров облачных услуг.
Спасибо, можно сказать автор вынул из моей головы и структурировал все те мысли что смущали меня когда я сам начал собеседовать и нанимать людей.
Вроде простая мысль, но увы не всегда очевидная для начинающих руководителей - "собеседование это не экзамен". Еще раз спасибо в общем.
1) Писать о том что тебе действительно интересно;
2) Писать просто, использовать корректные термины, объяснять сложные абстракции иллюстрациями, схемами и примерами;
3) Перед стартом своей работы ознакомиться с тем что уже написано на эту тему;
4) Не забывать что статья должна нести в себе какойто смысл и служить цели. Чего вы хотите чтобы читатель узнал/понял/попробовал после прочтения;
5) Прочитать статью вслух перед публикацией. Так можно определить слабые места, несогласованность окончаний, потерю основной мысли, сюжетной нити и т.д.
Как понял я, в первом случае (все на дедике) вы получаете доступ до объекта который имеет публичный адрес. А на нем находится вся ваша инфраструктура в том числе и БД как на блюдечке! И совсем не факт что он получил доступ к "коду приложения". Он просто получил доступ ко всей файловой системе, этого достаточно.
Во втором случае (на дедике только то что нужно), вы получаете доступ только к той части инфраструктуры которой нужно смотреть наружу - например веб-сервер, прокси сервер и тп. Дальше нужно проводить анализ инфраструктуры и продумывать следующие шаги атаки. Это выглядит более трудоемким.
Но да вы правы, при желании взломать можно все что угодно, это всего лишь вопрос времени и ресурсов.
Екатерина, спасибо за годную статью. Возьму ваши примеры на вооружение.
Я как раз сейчас искал чужой опыт проведение ретро на удаленке, но в русскоязычном сегменте интернета это оказалось нетривиальной задачей. В общем спасибо!
Автор модели DISC написал о ней книгу «Emotions of Normal People». Последние издание которой цитируются более чем в 700 научных трудах, если верить Google Academy.
Ну а увлечение комиксами и феминизмом еще никого не делало плохим или непрофессиональным человеком.
Здорово, что у нас у всех есть уникальные способы отличить компетентного человека от некомпетентного 🙂 И спасибо, что поделились своим.
А расскажите, что в биографии автора вас смутило? Также интересно, какие научно обоснованные подходы/инструменты вы используете при выстраивании коммуникаций с коллегами.
Спасибо за интересную точку зрения!
Качество общения с коллегой и качество выполнения им задач — объекты весьма разные. Понять это можно, подумав о метриках, которые мы бы использовали для их оценки.
Еще раз соглашусь с вами насчет CJM. Да, он является лучшей практикой для разработки продукта, основывающегося на потребностях пользователей, и это факт.
Но давайте посмотрим на это с другой стороны. Как CJM поможет мне понять:
— Продал ли я свою идею коллеге?
— Хорошо ли коллега меня понял?
— Что вообще важно для моего коллеги? На чем стоит заострить внимание, когда я, например, буду показывать ему тот же CJM покупки с сайта?
— Правильную ли мотивацию я выбрал?
— Не задел ли я случайно его чувств?
— Не повел ли я себя как мудак при разговоре с коллегой?
Иными словами я не предлагаю вам метод персон для развития продукта. Я предлагаю вам модель DISK для ретроспективы и улучшения ваших отношений с людьми. Людьми, с которыми вы проводите большую часть вашей жизни, — вашими коллегами.
Коллега, спасибо большое за интерес к статье. Согласен, что в рамках разработки продукта правильно использовать CJM, а еще JTBD, CustDev, Lean Canvas, HADI и т.д. Но в этом тексте мы рассматриваем инструмент повышения качества общения с коллегами на работе. Кажется, здесь CJM — не помощник.
Спасибо за интерес к моей статье, я тоже часто думаю на эту тему. Однако делать такое сравнение кое-как не хочется.
Постараюсь найти время и силы для хорошего сравнения в этом году.
Спасибо за ваш опыт коллега, приятно когда статья вызывает отклик)
Спасибо за ваш комментарий, поясню: да, Puppet один из инструментов, который можно использовать в концепции IaC, а можно использовать и вне IaC. Сама же концепция IaC появилась позже, примерно в 2006-2007 вместе с распространением популярности Amazon cloud. Но согласитесь, дата рождения технологии не всегда совпадает с ее распространением в мире? Подробнее можно почитать о кривой проникновения технологии - тут.
Ваш комментарий про AD + GPO и тем более MS Answer file 95 я, увы, не понял. Эти инструменты вообще не про IaC. Часто вы видели чтобы с их помощью создавалсь виртуальная, тонко настроенная инфраструктура, сети, маршрутизация, виртуальные сети, балансировщики? Лично я такого не встречал.
Насчет того почему IaC дополняет DevOps инструменты, и почему это действительно важно можно ознакомится тут.
Я не планировал раскрывать термин DevOps, статья всеже чуть-чуть не об этом. Но спасибо вам, что дополнили и раскрыли этот момент в комментарии.
Как обычно интересно и полезно. Спасибо за годноту.
Спасибо за интерес к продукту! Да, у нас есть живая миграция точки выполнения ВМ с узла на узел. Кроме того, есть живая миграция дисков виртуальных машин из хранилища в хранилище.
Добавил информацию в таблице.
Коллега, в нашей экосистеме теперь два продукта, вы можете использовать любой из них. Тот, что больше релевантен для вас, для ваших задач.
Полностью с вами согласен, сотни ВМ обслуживать из интерфейса невозможно. И поэтому у нас есть два инструмента: like REST API со свагером и еще свой провайдер в Terraform. Документация тут. Они позволяют решать задачи управления сотнями и даже тысячами ВМ.
Спасибо большое за ваш комментарий!
Спасибо вам за комментарий, вижу ваш интерес, возможно в будущем займусь сравнением и с OpenStack.
Спасибо вам за ваш комментарий, возможно я найду силы и время заняться написанием такого сравнения с ProxMox. Мне кажется, что это серьезная работа которую нельзя делать абы как.