ага "главный вопрос — сможет ли он вписаться в культуру Anthropic.". а Мария Ивановна из села соседнего, прошла курс (вставить ссылку) и устроилась в Anthropic руководителем тимлидов, тк борщ на всех сварила и сметанку принесла. Она смогла, и ты сможешь!
хм, "у неё появилось больше предложений о работе", те предложения были, но она не согласилась?! Это как в той книге сверхуспешных, где "Открываем первые страницы. У моих родителей был самолет"?
А что плохого, что будет больше контента на тему Zero Trust? Тема была всегда актуально и просвещать нужно постоянно, что бы не забывали. Я думаю, что вы прекрасно знаете про разнообразие, закрытие всего и вся на разных уровнях, количества решения от вендоров, а банально, придя в офис перетыкаете шнурок от принтера в свой ноут и вы уже в корп.сети. Много историй ходит в интернете. Что касается VDI, это вариант решения для для удаленщиков, чтобы ИБ спецам было проще контролировать. На мой взгляд, самое простое и эффективное. Вы можете предложить свой вариант.
Если все давать на откуп вендору, чтобы он все продумал, и телепатическим способом узнал про нюансы до реализации - это слишком хорошо был бы. На практике, специалисты должны быть с обоих сторон. Я про Заказчика и Вендора. Заказчик должен понимать, что конкретно ему нужно, является ли это для него угрозой и закрывать согласно имеющемуся бюджету и приоритету.
Не соглашусь с вами! Это выдержка из большого материала про ИБ. Аудитории на конференции хорошо она зашла и было много вопросов, как на минималках реализовать защиту на уровне zerotrast. Эта статья как ответ на многие вопросы.
кстати, полностью с вами согласен. Для своих личных маленьких инсталляция для тестов, я проксмос всегда брал, когда был целиком хост/нода в наличии, а вот где нужно было быстро и чтобы было кому задавать вопросы ispsystem решения рассматривал. Но это все под личные маленькие локальные ИТ задачки.
Не совсем вас понял. Я не видел провайдеров, которые в 2 раза увеличивали счет за ресурсы. Если мой личный опыт, рассматривать как ответ, то по стоимости домашнего ПК, который собирал себе 1,5 года назад и сейчас идентичное железо в 2 раза дороже стоит в маркетплейсе, увы.
в данной статье vmware суммарно, как вендор решение платформы виртуализации с ESXI, vSphere, CloudDirector, vSAN и прочие, без разбивки на конкретные составляющие.
все верно. Совсем недавно было у меня так: был проект "чтобы работала" на одном хосте, то ставил esxi free, если надо было чуть сложнее, то ставил hyper-v, если для мини внутреннего хостинга, то PROXMOX и так далее А сейчас стало чуть сложнее, особенно требования ИБ и регуляторов и приходится изучать прочие решения
Вы правы. По причине объема текста статьи, пока только эту часть опубликовали. По платформам виртуализации, особенно отечественным, требуется уточнения данных. Этим как раз и занимаюсь.
Про «85%» — да, это упрощение для статьи. В реальности граница размыта. Есть вещи, которые однозначно на стороне платформы: установка, патчи, failover, инфраструктурный мониторинг. А есть зона «зависит» — ваш случай с WAL как раз оттуда.
По вашему кейсу с UPDATE и WAL. Managed тут не значит магия. Платформа должна увидеть рост WAL и отставание реплик раньше падения, поднять алерт, дать рекомендации (увеличить диск, поменять retention, посмотреть на паттерн).
Но решить за клиента «это нормальная бизнес-логика или баг в коде» — не может. Троттлить запись автоматически опасно, можем сломать процесс. Молча доводить до падения — тоже плохо.
Получается совместная работа: мы видим метрики и говорим «проблема здесь», клиент решает «это норма, давайте масштабируем» или «да, баг у нас, фиксим».
По «жирный инстанс, но медленно». Согласен, просто «смотрите метрики» недостаточно. Минимум — разобрать, где узкое место: в запросе/индексах или в железе. Если в запросе — показать план, explain, дать рекомендации. Если в инфраструктуре — объяснить конкретно что (IOPS, CPU wait, сеть).
DBaaS не убирает необходимость понимать Postgres. Он убирает рутину (патчи, бэкапы, failover) и берёт первую линию диагностики. Сложные кейсы всё равно требуют диалога, иначе это просто аренда железа с Postgres сверху.
Отдельно отвечу вам, замечания ваши по делу, но в большей степени относятся, если бы статья была как полноценная инструкция к действию "как поднять СУБД руками". По формату статьи - приведены инструменты, которые могут быть задействованы по разному или вообще не использоваться. Это мой опыт. Про split-brain - подправлю текст.
По прочим комментариям, я возьму на доработку в рамках отдельной статьи. Буду рад если её также проревъюите!
Да, вы совершенно правы. По этой причине уже активно пилотируется версия выше 7.3
ага "главный вопрос — сможет ли он вписаться в культуру Anthropic.". а Мария Ивановна из села соседнего, прошла курс (вставить ссылку) и устроилась в Anthropic руководителем тимлидов, тк борщ на всех сварила и сметанку принесла.
Она смогла, и ты сможешь!
в отдельном стоящем случае, да вы полностью правы. 258 дней, - глобальный средний показатель времени Dwell Time (жизни угрозы). Те среднемаксимальное время когда нашли проблему и ее закрыли или приняли меры. Отчет IBM и Ponemon Institute «Стоимость утечки данных в 2024 году»
хм, "у неё появилось больше предложений о работе", те предложения были, но она не согласилась?! Это как в той книге сверхуспешных, где "Открываем первые страницы. У моих родителей был самолет"?
Спасибо. Рад был стараться.
Согласен с вами, тема обобщения и структурирования материалов задача из сложных и нужных
Если есть предложения темы, которая вам интересная в рамках Zero Trust, с удовольствием ее освящу и соавторов найду. Либо тут или в ЛС пишите. Спасибо
А что плохого, что будет больше контента на тему Zero Trust? Тема была всегда актуально и просвещать нужно постоянно, что бы не забывали. Я думаю, что вы прекрасно знаете про разнообразие, закрытие всего и вся на разных уровнях, количества решения от вендоров, а банально, придя в офис перетыкаете шнурок от принтера в свой ноут и вы уже в корп.сети. Много историй ходит в интернете.
Что касается VDI, это вариант решения для для удаленщиков, чтобы ИБ спецам было проще контролировать. На мой взгляд, самое простое и эффективное. Вы можете предложить свой вариант.
полностью с вами согласен. Самое сложное это ТЗ в данном процессе. Одни должны все описать, а другие посчитать и не просчитать.
Если все давать на откуп вендору, чтобы он все продумал, и телепатическим способом узнал про нюансы до реализации - это слишком хорошо был бы.
На практике, специалисты должны быть с обоих сторон. Я про Заказчика и Вендора. Заказчик должен понимать, что конкретно ему нужно, является ли это для него угрозой и закрывать согласно имеющемуся бюджету и приоритету.
Конкретного вендора по защите ZeroTrust вы выбирайте самостоятельно. Статья не про рекламу.
Не соглашусь с вами! Это выдержка из большого материала про ИБ. Аудитории на конференции хорошо она зашла и было много вопросов, как на минималках реализовать защиту на уровне zerotrast.
Эта статья как ответ на многие вопросы.
кстати, полностью с вами согласен. Для своих личных маленьких инсталляция для тестов, я проксмос всегда брал, когда был целиком хост/нода в наличии, а вот где нужно было быстро и чтобы было кому задавать вопросы ispsystem решения рассматривал. Но это все под личные маленькие локальные ИТ задачки.
Я уже больше шести лет не слышу о них в своём окружении.
У вас есть секретная информация?
Не совсем вас понял. Я не видел провайдеров, которые в 2 раза увеличивали счет за ресурсы. Если мой личный опыт, рассматривать как ответ, то по стоимости домашнего ПК, который собирал себе 1,5 года назад и сейчас идентичное железо в 2 раза дороже стоит в маркетплейсе, увы.
в данной статье vmware суммарно, как вендор решение платформы виртуализации с ESXI, vSphere, CloudDirector, vSAN и прочие, без разбивки на конкретные составляющие.
все верно. Совсем недавно было у меня так: был проект "чтобы работала" на одном хосте, то ставил esxi free, если надо было чуть сложнее, то ставил hyper-v, если для мини внутреннего хостинга, то PROXMOX и так далее
А сейчас стало чуть сложнее, особенно требования ИБ и регуляторов и приходится изучать прочие решения
Вы правы. По причине объема текста статьи, пока только эту часть опубликовали. По платформам виртуализации, особенно отечественным, требуется уточнения данных. Этим как раз и занимаюсь.
Спасибо, что напомнили про CloudNativePG. Давно уже хотел её начать использовать в проде.
Про «85%» — да, это упрощение для статьи. В реальности граница размыта. Есть вещи, которые однозначно на стороне платформы: установка, патчи, failover, инфраструктурный мониторинг. А есть зона «зависит» — ваш случай с WAL как раз оттуда.
По вашему кейсу с UPDATE и WAL.
Managed тут не значит магия. Платформа должна увидеть рост WAL и отставание реплик раньше падения, поднять алерт, дать рекомендации (увеличить диск, поменять retention, посмотреть на паттерн).
Но решить за клиента «это нормальная бизнес-логика или баг в коде» — не может. Троттлить запись автоматически опасно, можем сломать процесс. Молча доводить до падения — тоже плохо.
Получается совместная работа: мы видим метрики и говорим «проблема здесь», клиент решает «это норма, давайте масштабируем» или «да, баг у нас, фиксим».
По «жирный инстанс, но медленно».
Согласен, просто «смотрите метрики» недостаточно. Минимум — разобрать, где узкое место: в запросе/индексах или в железе. Если в запросе — показать план, explain, дать рекомендации. Если в инфраструктуре — объяснить конкретно что (IOPS, CPU wait, сеть).
DBaaS не убирает необходимость понимать Postgres. Он убирает рутину (патчи, бэкапы, failover) и берёт первую линию диагностики. Сложные кейсы всё равно требуют диалога, иначе это просто аренда железа с Postgres сверху.
Отдельно отвечу вам, замечания ваши по делу, но в большей степени относятся, если бы статья была как полноценная инструкция к действию "как поднять СУБД руками". По формату статьи - приведены инструменты, которые могут быть задействованы по разному или вообще не использоваться. Это мой опыт.
Про split-brain - подправлю текст.
По прочим комментариям, я возьму на доработку в рамках отдельной статьи. Буду рад если её также проревъюите!