Скриптам и программам доверяю больше, чем людям, себе же — из всех людей — меньше всего. Потому как себе любимому больше всего позволяю. И поэтому, допустить выполнение действия, которому не придумал отката — не реализую. Иногда бывает помутнение рассудка и можешь просто перепутать. Все мы люди. Хотя все это специфично ;) Если сбить пароль, или настройки кроме сетевых — можно еще раз запустить скрипт и внести изменения обратно. А вот с сетевыми настройками — тут как гильотниа — голова отлетает и обратно ее не пришьешь, если только ножками все не оббежать.
Больше 12 лет использую WMI как средство администрирования по части сбора и анализа различной статистики с кучи серверов. Был случай, когда экстренно с полуторатысячи клиентских мест он помог собрать нужные сведения.
Но, надо сказать, никогда не решался скриптом разом и без логгирования править настройки на куче мест. Лень-то она конечно двигатель прогресса, но не все же мы самураи. Преклоняюсь перед «смелостью» автора.
Самое интересное, где-то как раз с 2008 — 2011 практически перестал пользоваться болванками. Надо, кстати, глянуть, что там со старыми архивами. Как-то не угадал наш светоч кинематографа с какого именно технического решения деньги выжимать.
Ну вот, а мне в школе говорили, что выброшенный пластиковый пакет и что-то там про полтысячелетия и природу. Короче — привет зеленым. Пластиковые пакеты теперь практически продукт, сырье для животного мира. Природа под любые хитроумные выверты людей приспособится.
Если производственный процесс основывать только на дисциплине, то это будет мертвый, заранее регламентированный, жестко описанный процесс. Типа работ на конвеере, где люди гайки штампуют или делопроизводитель, который перекладывает бумажки с одной стопки в другую (вспомни Гоголевскую Шинель, в кого превратился там главный герой).
Если необходимо развитие, а разработка таковой и является. Да любой бизнес — дело тоже творческое, то нужен будет и мотивирующий фактор.
«DevOps» — ами зачастую назначают мальчиков (дядечек), которые по факту просто бегают от одних к другим (как официантка в ресторане). Вносят какие-то предложения, правильные, конструктивные, но на которые всем, как правило плевать. Вот там, где DevOps — должны решения приниматься, а для этого через них должны идти финансовые потоки. Пока это не так — они так и будут бегать как официант в ресторане: ни на заказ повлиять толком не могут, ни приготовить ничего. Только улыбаться. А так идея — да, идея правильная.
Интересный пример, что-то можно будет взять на вооружение. Но надо сказать — вот это вот утопия: «разработчики должны писать правильные приложения». К сожалению, на продакшене часто разработчики и администраторы разделены различными менеджерами в чьих руках финансы. И последних мало интересуют проблемы «негр...», ой — администраторов. ПО, как правило «пускается в плавание» как есть. Архитектура не интересует менеджеров, бэкенд важнее и основные технологические операции. Почему оно должно работать — а вот для этого и нужен админ, обратной связи нет с разработчиком.
Для такой архитектуры нужно очень хорошо масштабируемое ПО.
Мы потому и спрашиваем. Всплыло в этом докладе то, что мягко говоря не ожидаешь от такого уровня как яндекс, которым практически вся страна пользуется. Вот и хотелось бы узнать про реализацию, хотя бы примерную, других сервисов.
К своей софтине всегда делаю логгирование SQL запросов со штампом времени. Нет никакой проблемы повторить все DML-ки с определенного момента времени. Или я чего-то недопонимаю? Отдельно можно создать не просто бэкапы, а полные копии-хранилища данных и накатывать на них эти самые запросы. Будет соотношение бэкап-исходные данные в соотношении 1:1, при этом из бэкапа восстановиться можно будет без долгого копирования всех терабайтов самой БД. Накатывать с отставанием в те же самые 7 дней.
А яндекс.деньги на какой реализации у них живут?! Как раз ведь и народ.ру был выкинут яндексом то же в то же время. Видать реально разрослись. Народ.ру жалко конечно.
Да и на стандарте много раз, на внедрениях, где руководство зажимало деньги, реализовывал скриптовый стендбай со своим мониторингом. Работало годами и переключалось нормально.
Непонятно отношение к коллегам: «Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её. Очень наглые ребята.» А сам Вова и его команда бесплатно все вот это реализовывали?
PostGreSQL хорош своими коммьюнити, но это будет не всегда. Чем больше будет серьезных проектов, где «большие деньги»крутятся и отвественность большая, все захотят, что бы советчики «отвечали» за свои советы. И все разом махнет из открытой коммьюнити на какой-нибудь платный сервис. Хотя не спорю — у Оракл поддержка — это нечто запредельное. И тогда вот станет не понятно, стоило ла овчинка выделки, тем более, что железа уже сейчас стала в 3 раза больше: «Без ложек дёгтя не бывает. У нас сейчас в 3 раза больше железа под PostgreSQL, но это ничто по сравнению со стоимостью Oracle.»
Данные с СУБД Oracle, например можно синхронизировать (горячее резервирование) между несколькими удаленными экземплярами средствами самой же СУБД. При этом если делать синхронизацию на уровне систем хранения, собственно данные в целевых точках синхронизации, не будут валидными с точки зрения СУБД.
1) Если все данные предприятия хранятся в самой базе данных, то зачем способ синхронизации на уровне устройств хранения данных нужен?!
«от конкурентов спасаются — методом ддоса» — видать у них высший менеджмент из бывших IT-ников. Посмотрим, чем это все закончится. Думаю, инвестиции в магнит именно на данном этапе пойдут ему не во благо. Как говорится, рыба с головы… ну сколько тушку не наполняй черной икрой, при такой голове от этого толку не будет.
Кстати, у Магнита пошлое какое-то не здоровое расширение. Видать менеджеры так увлеклись ставить флажки на картах городов, что у же забыли о таких понятиях как рентабельность, ассортимент. Проще поставить дополнительную кассу, или нанять персонал, чтобы простаивала не половина касс в существующих магазинах, а скажем, только одна. Как показывает практика — легче добавить еще один магазин. Возможно это реалии только Саратова. Откройте карту, например участок между улицами Беговая, Беговая-1 и Беговая-5 — 500 м. В прямом смысле слова 5 — 10 домов высотности 5 — 9 этажей. Когда идешь домой, заходишь в магнит не из-за ассортимента, а просто если мысль пришла в голову что-то купить проходя именно мимо этого магазина. Это немного странно. При этом планы Магнита были на 2016 г. более оптимистичными именно в плане расширения числа магазинов и по своим отчетностям они их «сильно не достигли». Надо сказать, обилие магнитов меня загоняет в единственную на этом участке пятерочку ;).
Может кто-то в магнит сделал сильные инвестиции и заодно команду на увеличение числа «точек»?
Но, надо сказать, никогда не решался скриптом разом и без логгирования править настройки на куче мест. Лень-то она конечно двигатель прогресса, но не все же мы самураи. Преклоняюсь перед «смелостью» автора.
Если необходимо развитие, а разработка таковой и является. Да любой бизнес — дело тоже творческое, то нужен будет и мотивирующий фактор.
Для такой архитектуры нужно очень хорошо масштабируемое ПО.
PostGreSQL хорош своими коммьюнити, но это будет не всегда. Чем больше будет серьезных проектов, где «большие деньги»крутятся и отвественность большая, все захотят, что бы советчики «отвечали» за свои советы. И все разом махнет из открытой коммьюнити на какой-нибудь платный сервис. Хотя не спорю — у Оракл поддержка — это нечто запредельное. И тогда вот станет не понятно, стоило ла овчинка выделки, тем более, что железа уже сейчас стала в 3 раза больше: «Без ложек дёгтя не бывает. У нас сейчас в 3 раза больше железа под PostgreSQL, но это ничто по сравнению со стоимостью Oracle.»
1) Если все данные предприятия хранятся в самой базе данных, то зачем способ синхронизации на уровне устройств хранения данных нужен?!
2) Каковы конкретные примеры использования?
Может кто-то в магнит сделал сильные инвестиции и заодно команду на увеличение числа «точек»?