Pull to refresh
3
0
Сергей @Sergery8205

Пользователь

Send message
Скриптам и программам доверяю больше, чем людям, себе же — из всех людей — меньше всего. Потому как себе любимому больше всего позволяю. И поэтому, допустить выполнение действия, которому не придумал отката — не реализую. Иногда бывает помутнение рассудка и можешь просто перепутать. Все мы люди. Хотя все это специфично ;) Если сбить пароль, или настройки кроме сетевых — можно еще раз запустить скрипт и внести изменения обратно. А вот с сетевыми настройками — тут как гильотниа — голова отлетает и обратно ее не пришьешь, если только ножками все не оббежать.
Больше 12 лет использую WMI как средство администрирования по части сбора и анализа различной статистики с кучи серверов. Был случай, когда экстренно с полуторатысячи клиентских мест он помог собрать нужные сведения.

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

1) Если все данные предприятия хранятся в самой базе данных, то зачем способ синхронизации на уровне устройств хранения данных нужен?!

2) Каковы конкретные примеры использования?
«от конкурентов спасаются — методом ддоса» — видать у них высший менеджмент из бывших IT-ников. Посмотрим, чем это все закончится. Думаю, инвестиции в магнит именно на данном этапе пойдут ему не во благо. Как говорится, рыба с головы… ну сколько тушку не наполняй черной икрой, при такой голове от этого толку не будет.
Кстати, у Магнита пошлое какое-то не здоровое расширение. Видать менеджеры так увлеклись ставить флажки на картах городов, что у же забыли о таких понятиях как рентабельность, ассортимент. Проще поставить дополнительную кассу, или нанять персонал, чтобы простаивала не половина касс в существующих магазинах, а скажем, только одна. Как показывает практика — легче добавить еще один магазин. Возможно это реалии только Саратова. Откройте карту, например участок между улицами Беговая, Беговая-1 и Беговая-5 — 500 м. В прямом смысле слова 5 — 10 домов высотности 5 — 9 этажей. Когда идешь домой, заходишь в магнит не из-за ассортимента, а просто если мысль пришла в голову что-то купить проходя именно мимо этого магазина. Это немного странно. При этом планы Магнита были на 2016 г. более оптимистичными именно в плане расширения числа магазинов и по своим отчетностям они их «сильно не достигли». Надо сказать, обилие магнитов меня загоняет в единственную на этом участке пятерочку ;).

Может кто-то в магнит сделал сильные инвестиции и заодно команду на увеличение числа «точек»?

Information

Rating
Does not participate
Location
Саратов, Саратовская обл., Россия
Date of birth
Registered
Activity