Про танки. Начало
Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.
Начнем с того, что любая игра, особенно онлайн, должна чем-то удерживать игроков, заставлять их возвращаться, максимально вовлекать их в игровой процесс для получения максимальной прибыли с микротранзакций.
Так работают не только танки, так работает любая онлайн игра. Но именно танки сумели сделать игровой процесс максимально токсичным и заставить игроков ходить на него как на работу.
И вместо того, чтобы отвлекать, развлекать и дарить положительные эмоции игра все чаще и чаще доставляет негатив и заставляет ее закрывать в раздраженном состоянии. И они хотят, чтобы за это мы еще платили деньги?
Как вообще должен функционировать данный проект? Основная цель геймплея – прокачка веток, от слабых танков к сильным и крутым. Но прокачка тесно связана с экономикой проекта. Потому что нельзя просто так брать и качать.
Ваш ключ к прокачке – опыт, чем активнее и эффективнее вы действуете в бою, тем больше опыта получаете, тем быстрее вы сможете прокачаться. Но опыт — это еще не все, после прокачки новые модули и новую технику нужно купить, на это требуются кредиты, которые тоже можно заработать в бою.
Чем выше уровень, тем больше опыта и кредитов вы вывозите за бой, но и тем выше ваши накладные расходы. В былые времена уже начиная с 8-го уровня играть в плюс было проблематично даже при победе, а десятки стабильно уходили в минус.
Это нормально, потому что в экономической модели игры предусмотрен премиум-аккаунт, немного живых денег в месяц и вот вы уже играете в плюс на восьмерках и в ноль на десятках.
А хотите немного пофармить или прокачать пересаженный экипаж – вот вам премиум техника, тоже за реальные деньги, она немного хуже прокачиваемой, но дает повышенные кредиты и опыт. Первые премы именно такими и были.
И все шло как бы себе неплохо, пока где-то там наверху не решили, что нужно больше золота. И приняли крайне сомнительные решения.
Старожилы должны помнить «песок» - уровни от первого по четвертый, где были быстрые тачанки, скоротечные бои и всякая веселая дичь. Но так или иначе, в песке было весело и там же начинающие осваивали основы игры практически в аркадном режиме.
Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.
Теперь там новый «песок», с пятого по седьмой. Многим нравится, многие там играют. Но настоящий песок увы потерян, хотя там были и есть интересные машинки, но сегодня там делать нечего.
Если мы сунемся выше, то тоже увидим, что начиная с восьмого уровня бал правят премы, их много, их раздавали за всякие активности, марафоны, ящики, и они, внезапно, лучше прокачиваемых машин.
Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.
А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.
Новые ветки качнуть можно, но что значит «качнуть»? Открыть за чертежи, серебро и свободку, чего у каждого обычно с запасом. Но при это помнить, что все это ненадолго и скоро новые «имбы» просто понерфят.
Именно так произошло с огнеметами, которые после их появления были просто фановыми и разрывали рандом, а теперь пойди найди огнемет в команде.
И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.
А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…
Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…
Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.
Начнем с того, что любая игра, особенно онлайн, должна чем-то удерживать игроков, заставлять их возвращаться, максимально вовлекать их в игровой процесс для получения максимальной прибыли с микротранзакций.
Так работают не только танки, так работает любая онлайн игра. Но именно танки сумели сделать игровой процесс максимально токсичным и заставить игроков ходить на него как на работу.
И вместо того, чтобы отвлекать, развлекать и дарить положительные эмоции игра все чаще и чаще доставляет негатив и заставляет ее закрывать в раздраженном состоянии. И они хотят, чтобы за это мы еще платили деньги?
Как вообще должен функционировать данный проект? Основная цель геймплея – прокачка веток, от слабых танков к сильным и крутым. Но прокачка тесно связана с экономикой проекта. Потому что нельзя просто так брать и качать.
Ваш ключ к прокачке – опыт, чем активнее и эффективнее вы действуете в бою, тем больше опыта получаете, тем быстрее вы сможете прокачаться. Но опыт — это еще не все, после прокачки новые модули и новую технику нужно купить, на это требуются кредиты, которые тоже можно заработать в бою.
Чем выше уровень, тем больше опыта и кредитов вы вывозите за бой, но и тем выше ваши накладные расходы. В былые времена уже начиная с 8-го уровня играть в плюс было проблематично даже при победе, а десятки стабильно уходили в минус.
Это нормально, потому что в экономической модели игры предусмотрен премиум-аккаунт, немного живых денег в месяц и вот вы уже играете в плюс на восьмерках и в ноль на десятках.
А хотите немного пофармить или прокачать пересаженный экипаж – вот вам премиум техника, тоже за реальные деньги, она немного хуже прокачиваемой, но дает повышенные кредиты и опыт. Первые премы именно такими и были.
И все шло как бы себе неплохо, пока где-то там наверху не решили, что нужно больше золота. И приняли крайне сомнительные решения.
Старожилы должны помнить «песок» - уровни от первого по четвертый, где были быстрые тачанки, скоротечные бои и всякая веселая дичь. Но так или иначе, в песке было весело и там же начинающие осваивали основы игры практически в аркадном режиме.
Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.
Теперь там новый «песок», с пятого по седьмой. Многим нравится, многие там играют. Но настоящий песок увы потерян, хотя там были и есть интересные машинки, но сегодня там делать нечего.
Если мы сунемся выше, то тоже увидим, что начиная с восьмого уровня бал правят премы, их много, их раздавали за всякие активности, марафоны, ящики, и они, внезапно, лучше прокачиваемых машин.
Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.
А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.
Новые ветки качнуть можно, но что значит «качнуть»? Открыть за чертежи, серебро и свободку, чего у каждого обычно с запасом. Но при это помнить, что все это ненадолго и скоро новые «имбы» просто понерфят.
Именно так произошло с огнеметами, которые после их появления были просто фановыми и разрывали рандом, а теперь пойди найди огнемет в команде.
И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.
А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…
Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…
🤣30💯8❤7🤮3👍2
Полезная команда tee в Linux
Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.
Как и все классические утилиты
Например:
Это удобно для фиксации промежуточного результата, особенно в целях логирования или отладки.
По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ
Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по
Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.
Как и все классические утилиты
tee выполняет одну задачу, но делает ее хорошо. Ее смысл можно представить в виде буквы Т - команда принимает на вход стандартны поток ввода и выдает его же в стандартный поток вывода, одновременно записывая его содержимое в один или несколько файлов.Например:
command | tee file1.log
file1.log. Это удобно для фиксации промежуточного результата, особенно в целях логирования или отладки.
command1 | tee file1.log | command2
По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ
-a:command1 | tee -a file1.log
-i, который предписывает игнорировать команды завершения, такие как Ctrl + C. Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по
Ctrl + C, при наличии данного ключа tee продолжит работу и корректно завершит запись в файл.
ping ya.ru | tee -i ping_ya.txt
tee - это повышение прав для записи в системные файлы. Например:
sudo echo "строка_текста" > /etc/myconf.conf
echo "строка_текста" | sudo tee /etc/myconf.conf
tee - простая, но весьма удобная и функциональная команда.👍24👌11🔥8❤4⚡3
Как быстро вычислить отвечающие на Ping узлы подсети в терминале Linux
Такая задача встречается довольно часто, когда вам нужно получить список «живых» узлов подсети, неважно с какими целями и сделать это нужно быстро и просто.
Вам поможет утилита fping, для ее установки воспользуйтесь командой:
Затем запустите ее с ключами:
Разберем части команды подробнее:
▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping
▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае
▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах
Как видим, поставленная нами задача решена просто и быстро.
Но это еще не все, рекомендуем ознакомиться со всеми возможностями fping выполнив:
Кстати, советуем регулярно обращаться к справке даже тех утилит, которые вы знаете, это поможет узнать что-то новое (новые ключи) или вспомнить некоторые забытые возможности.
Такая задача встречается довольно часто, когда вам нужно получить список «живых» узлов подсети, неважно с какими целями и сделать это нужно быстро и просто.
Вам поможет утилита fping, для ее установки воспользуйтесь командой:
apt install fping
Затем запустите ее с ключами:
fping -a -g 192.168.172.0/24 2>/dev/null
Разберем части команды подробнее:
▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping
▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае
▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах
Как видим, поставленная нами задача решена просто и быстро.
Но это еще не все, рекомендуем ознакомиться со всеми возможностями fping выполнив:
fping -h
Кстати, советуем регулярно обращаться к справке даже тех утилит, которые вы знаете, это поможет узнать что-то новое (новые ключи) или вспомнить некоторые забытые возможности.
1👍46🤝3❤2
Логическая бомба
Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.
Логическая бомба – это код, который при наступлении некоторых условий, которые можно заранее просчитать и предвидеть, производит некоторые деструктивные действия. И здесь трудно сослаться на случайность или недосмотр.
Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.
Рассмотрим классический пример, очистка устаревших данных, например, бекапов:
Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.
1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.
Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.
2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.
3️⃣ Теперь – самое неочевидное –
Поэтому постараемся сразу учесть эти моменты. Удалять всегда нужно привязываясь не ко времени или еще каким-то внешним параметрам, а по количеству остающихся копий, в этом случае даже если у вас перестанут создаваться копии, то последние всегда останутся. Во многих случаях это гораздо лучше ситуации, когда копии нет вообще.
Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).
Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:
Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.
Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.
Однозначно стало лучше, но не совсем. Что будет, если в эту папку попадут другие файлы? Они также будут удалены, при этом мы снова легко можем остаться без бекапов. Что будет если кто-то случайно закинет туда 100 новых файлов?
Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.
Допустим, наши бекапы имеют имя
Или даже
Чем более строгое совпадение в шаблоне – тем безопаснее, но во всем нужно видеть меру и вовремя остановиться, потому что если увлечься, то можно погрязнуть в проверках для совсем уже маловероятных условий или событий.
Да, и не забывайте логировать все что делают подобные скрипты, чтобы в случае какой-либо нештатной ситуации вы хотя бы могли выполнить работу над ошибками.
Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.
Логическая бомба – это код, который при наступлении некоторых условий, которые можно заранее просчитать и предвидеть, производит некоторые деструктивные действия. И здесь трудно сослаться на случайность или недосмотр.
Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.
Рассмотрим классический пример, очистка устаревших данных, например, бекапов:
find -type f -mtime +90 -exec rm -rf {} \;Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.
1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.
Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.
2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.
3️⃣ Теперь – самое неочевидное –
find, который не рекомендуется использовать в скриптах в силу ряда особенностей. В частности, если нам попадется файл с пробелами в имени, то строка будет разбита на две, что приведет к неожиданным последствиям. Чаще всего удаление не произойдет, но может случиться разное.Поэтому постараемся сразу учесть эти моменты. Удалять всегда нужно привязываясь не ко времени или еще каким-то внешним параметрам, а по количеству остающихся копий, в этом случае даже если у вас перестанут создаваться копии, то последние всегда останутся. Во многих случаях это гораздо лучше ситуации, когда копии нет вообще.
Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).
Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:
find /mnt/backup/ -type f -printf '%T@ "%p"\n' | \
sort -n | \
head -n -90 | \
awk '{print $2}' | \
xargs -I {} rm {}
Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.
Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.
Однозначно стало лучше, но не совсем. Что будет, если в эту папку попадут другие файлы? Они также будут удалены, при этом мы снова легко можем остаться без бекапов. Что будет если кто-то случайно закинет туда 100 новых файлов?
Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.
Допустим, наши бекапы имеют имя
base1-YYYY-MM-DD.dump, поэтому добавляем в строку поиска новое условие: find /mnt/backup/increment/ -type f -name "base1*.dump" -printf '%T@ "%p"\n'
Или даже
find... -name "base1-*-*-*.dump"...
Чем более строгое совпадение в шаблоне – тем безопаснее, но во всем нужно видеть меру и вовремя остановиться, потому что если увлечься, то можно погрязнуть в проверках для совсем уже маловероятных условий или событий.
Да, и не забывайте логировать все что делают подобные скрипты, чтобы в случае какой-либо нештатной ситуации вы хотя бы могли выполнить работу над ошибками.
👍28❤12👀2
This media is not supported in your browser
VIEW IN TELEGRAM
Шутки в IT бывают разные: бывают достаточно безобидные, а бывают очень злые и деструктивные.
Поэтому мы за первые. Старая добрая шутка на 1 апреля.
🤯🤯🤯
А какие IT-шутки знаете вы?
Поэтому мы за первые. Старая добрая шутка на 1 апреля.
🤯🤯🤯
А какие IT-шутки знаете вы?
😁30🤷♂3🤔1👌1🌭1
А в розетку включить не пробовали?
В продолжение первоапрельской темы расскажу реальный случай. Было это в начале нулевых и работал я в компьютерной фирме. Был у нас один достаточно крупный дилер из области и неплохой мужик сам по себе, назовем его Юра.
Так вот, Юра купил навороченный компьютер и что-то там его не совсем устраивало, поэтому он заранее с нами договорился, мол привезу свой комп, посмотрите, магарыч с меня.
В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.
Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.
Юра в шоке, ведь утром еще все включалось, зовем посмотреть самого – убеждается, то матери карачун. Далее стадия принятия и все такое.
И тут подходит к нам другой сотрудник техотдела Женя, внимательно на нас смотрит, а потом задает единственный, но меткий вопрос:
- А в розетку включить не пробовали?
Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.
В итоге оказалось, что проблемы Юры совсем не проблемы, мы быстро все решили и он поехал домой довольный. А Женя получил на домашний адрес большую пиццу.
В продолжение первоапрельской темы расскажу реальный случай. Было это в начале нулевых и работал я в компьютерной фирме. Был у нас один достаточно крупный дилер из области и неплохой мужик сам по себе, назовем его Юра.
Так вот, Юра купил навороченный компьютер и что-то там его не совсем устраивало, поэтому он заранее с нами договорился, мол привезу свой комп, посмотрите, магарыч с меня.
В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.
Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.
Юра в шоке, ведь утром еще все включалось, зовем посмотреть самого – убеждается, то матери карачун. Далее стадия принятия и все такое.
И тут подходит к нам другой сотрудник техотдела Женя, внимательно на нас смотрит, а потом задает единственный, но меткий вопрос:
- А в розетку включить не пробовали?
Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.
В итоге оказалось, что проблемы Юры совсем не проблемы, мы быстро все решили и он поехал домой довольный. А Женя получил на домашний адрес большую пиццу.
🤣28👍17🥱4😁1
Free или Available memory в Linux
В очередной раз сталкиваюсь с тем, что администраторы не понимают разницу между этими двумя показателями оперативной памяти в Linux.
Например, команда
Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти –
Можем ли мы сбросить буферы и очистить кеш? Да, можем, но когда после этого приложению потребуется какие-то данные или вызов библиотеки – то все это снова будет подгружено с жесткого диска и вполне может оказаться, что сделали мы только хуже, так как производительность системы на некоторое время упрется в производительность дисков, пока снова не будет заполнен кеш.
Поэтому в данной ситуации рассчитывать на 22,5 ГБ доступной памяти будет крайне неосмотрительно. В лучшем случае система может посчитать, что ей выгоднее сбросить страницы приложений в своп, вместо очистки кеша.
А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.
Кстати, системы мониторинга, тот же Zabbix будут смотреть именно на свободную память и выдавать вам алерты при ее исчерпании, хотя доступной памяти может быть еще много.
Также рекомендуем прочесть следующие статьи:
🔹 Linux - начинающим. Что такое пространства подкачки и как они работают
🔹 Linux - начинающим. Что такое OOM Killer и как он работает
В очередной раз сталкиваюсь с тем, что администраторы не понимают разницу между этими двумя показателями оперативной памяти в Linux.
Например, команда
free -m может дать нам такой вывод:
total used free shared buff/cache available
Mem: 60169 27996 9001 8472 23171 22576
Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти –
used в системе присутствует еще буферы и кеш - buff/cache, которые содержат разделяемые библиотеки, буферы ввода-вывода и т.д. и т.п., что позволяет системе меньше обращаться к диску. Можем ли мы сбросить буферы и очистить кеш? Да, можем, но когда после этого приложению потребуется какие-то данные или вызов библиотеки – то все это снова будет подгружено с жесткого диска и вполне может оказаться, что сделали мы только хуже, так как производительность системы на некоторое время упрется в производительность дисков, пока снова не будет заполнен кеш.
Поэтому в данной ситуации рассчитывать на 22,5 ГБ доступной памяти будет крайне неосмотрительно. В лучшем случае система может посчитать, что ей выгоднее сбросить страницы приложений в своп, вместо очистки кеша.
А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.
Кстати, системы мониторинга, тот же Zabbix будут смотреть именно на свободную память и выдавать вам алерты при ее исчерпании, хотя доступной памяти может быть еще много.
Также рекомендуем прочесть следующие статьи:
🔹 Linux - начинающим. Что такое пространства подкачки и как они работают
🔹 Linux - начинающим. Что такое OOM Killer и как он работает
👍22❤5🤮2👎1👌1
tcpdump – сеть как на ладони
При диагностике сетей очень важно убедиться в том, что нужные пакеты приходят на нужный узел и не просто приходят, а соответствуют критериям, которые вы указали в правилах фильтрации.
Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита
Для ее установки выполните:
После чего запустите ее с ключом -D, чтобы посмотреть какие интерфейсы в системе она видит и откуда может слушать трафик.
Далее мы можем просто запустить:
И сразу утонем в количестве информации, разобраться в которой будет решительно невозможно, поэтому, чтобы получить выжимку мы будем использовать фильтры, самые популярные из них:
▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp
Например, мы хотим посмотреть все пакеты с портом назначения
Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.
Теперь утилита нам покажет все пакеты, которые соответствую данному критерию: у которых транспортный протокол UDP и в поле порт назначения стоит 34567.
А если мы хотим посмотреть пакеты только от определенного узла, чтобы понять доходит к нам на сервер он него что-нибудь или нет. Усложним фильтр и добавим в него две группы условий. Для их соединения можно использовать логические выражения:
▫️AND
▫️OR
Отдельно для отрицания условия можно использовать
▫️NOT
Например:
Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.
Вот здесь может возникнуть вопрос, а почему нельзя написать так:
Вроде бы как пол логике вещей условия все равно соединяются как-бы по логическому И, однако это неверно. tcpdump требует явного указания условии соединения различных примитивов.
В нашем условии два примитива: хост и порт. Общий синтаксис примитива можно описать выражением:
В нашем случае примитивы взяты в фигурные скобки, каждый примитив должен явно соединяться через логический оператор. Например, наоборот, все пакеты, кроме определенного узла:
Если мы хотим захватить определенное количество пакетов, то используйте ключ
Данная команда захватит строго 50 пакетов, соответствующих условию.
Чтобы увеличить количество выводимой информации добавьте ключ
При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ
Но все это диагностика в реальном времени, а как быть, если мы хотим изучить полученный дамп подробно, в спокойной обстановке? Все просто, нужно записать его в файл, для этого предназначена опция
Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.
Записанный файл можно открыть любым подходящим ПО, наиболее популярным является открытый анализатор пакетов Wireshark.
При диагностике сетей очень важно убедиться в том, что нужные пакеты приходят на нужный узел и не просто приходят, а соответствуют критериям, которые вы указали в правилах фильтрации.
Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита
tcpdump. Для ее установки выполните:
apt install tcpdump
После чего запустите ее с ключом -D, чтобы посмотреть какие интерфейсы в системе она видит и откуда может слушать трафик.
tcpdump -D
Далее мы можем просто запустить:
tcpdump -i enp3s0
И сразу утонем в количестве информации, разобраться в которой будет решительно невозможно, поэтому, чтобы получить выжимку мы будем использовать фильтры, самые популярные из них:
▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp
Например, мы хотим посмотреть все пакеты с портом назначения
UDP 34567:tcpdump -i enp3s0 udp dst port 34567
Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.
Теперь утилита нам покажет все пакеты, которые соответствую данному критерию: у которых транспортный протокол UDP и в поле порт назначения стоит 34567.
А если мы хотим посмотреть пакеты только от определенного узла, чтобы понять доходит к нам на сервер он него что-нибудь или нет. Усложним фильтр и добавим в него две группы условий. Для их соединения можно использовать логические выражения:
▫️AND
▫️OR
Отдельно для отрицания условия можно использовать
▫️NOT
Например:
tcpdump -i enp3s0 src host 203.0.113.11 and udp dst port 34567
Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.
Вот здесь может возникнуть вопрос, а почему нельзя написать так:
tcpdump -i enp3s0 src host 203.0.113.11 udp dst port 34567
Вроде бы как пол логике вещей условия все равно соединяются как-бы по логическому И, однако это неверно. tcpdump требует явного указания условии соединения различных примитивов.
В нашем условии два примитива: хост и порт. Общий синтаксис примитива можно описать выражением:
[протокол] [направление] {host|net|port|portrange} значениеВ нашем случае примитивы взяты в фигурные скобки, каждый примитив должен явно соединяться через логический оператор. Например, наоборот, все пакеты, кроме определенного узла:
tcpdump -i enp3s0 udp dst port 34567 and not src host 203.0.113.11
Если мы хотим захватить определенное количество пакетов, то используйте ключ
-с:tcpdump -i enp3s0 -с 50 src host 203.0.113.11 and udp dst port 34567
Данная команда захватит строго 50 пакетов, соответствующих условию.
Чтобы увеличить количество выводимой информации добавьте ключ
-v[v], чем больше v вы указали, тем на более глубокий уровень будет разбираться информация пакета, но не обольщайтесь, если пакет не содержит дополнительных подробностей, но ничего нового вы не увидите.При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ
-n:tcpdump -i enp3s0 -n src host 203.0.113.11 and tcp dst port 22
Но все это диагностика в реальном времени, а как быть, если мы хотим изучить полученный дамп подробно, в спокойной обстановке? Все просто, нужно записать его в файл, для этого предназначена опция
-w:tcpdump -i enp3s0 -c 50 src host 203.0.113.11 and tcp dst port 22 -w mydump.pcap
Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.
Записанный файл можно открыть любым подходящим ПО, наиболее популярным является открытый анализатор пакетов Wireshark.
👍48
Гистерезис как средство стабилизации триггеров в Zabbix
Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению.
Это неприятно, так как приводит к резкому росту количества уведомлений и именно с этим явлением предлагают бороться, но на самом деле проблема лежит глубже, это проблема иллюзии восстановления.
О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания:
Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием
Поэтому набор значений:
а набор:
При этом фактически ситуация по памяти у нас не меняется и триггер или будет постоянно флапать или замолчит, и мы будем уверены, что ситуация выправилась, хотя на самом деле это не так и она продолжает оставаться критичной.
Как этого избежать? Ввести гистерезис, т.е. переводить триггер в состояние восстановления не сразу после того, как выражение срабатывания перестало работать, а с задержкой, когда мы будем уверены, что ситуация действительно нормализировалась.
Примем для этого значения порог срабатывания – 5%, при этом условием восстановления будет то, что за 5 минут ни одно значение не превысит этот порог. Теперь, после срабатывания триггера по памяти (штатное значение 90%) он не перейдет в состояние восстановления до тех пор, пока утилизация памяти стабильно не снизится менее 85%.
Для этого в настройках триггера добавим выражение восстановления и запишем туда следующий текст:
Обратите внимание, что здесь мы используем не
Таким образом мы ввели четкий 5% коридор, который не только предотвращает флаппинг триггера, но и защищает нас от иллюзии ложного восстановления, когда триггер перешел в состояние ОК, но значения остались близки к критическим.
Рекомендуем настроить подобный гистерезис для всех триггеров, имеющих критическое значение для системы, где мы должны быть твердо уверенны, что проблема действительно ушла, а не затаилась на время.
Кто постоянно работает с Zabbix знает такое явление как дребезг триггеров (или флаппинг), когда контролируемое значение колеблется около значения срабатывания триггера и приводит к постоянному его срабатыванию и восстановлению.
Это неприятно, так как приводит к резкому росту количества уведомлений и именно с этим явлением предлагают бороться, но на самом деле проблема лежит глубже, это проблема иллюзии восстановления.
О чем это мы? Давайте возьмем для примера триггер High memory utilization, который имеет следующее выражение срабатывания:
min(/Linux by Zabbix agent/vm.memory.utilization,5m)>{$MEMORY.UTIL.MAX}Оно означает, что если все значения за последние 5 минут были выше порога, то триггер сработает. Это обусловлено использованием
min(), фактически мы берем наименьшее значение за 5 минут и сравниваем с порогом.Поэтому набор значений:
89 90 91 89 92 95 – не сработает, min = 89
а набор:
91 93 95 91 92 94 – сработает, min = 91
При этом фактически ситуация по памяти у нас не меняется и триггер или будет постоянно флапать или замолчит, и мы будем уверены, что ситуация выправилась, хотя на самом деле это не так и она продолжает оставаться критичной.
Как этого избежать? Ввести гистерезис, т.е. переводить триггер в состояние восстановления не сразу после того, как выражение срабатывания перестало работать, а с задержкой, когда мы будем уверены, что ситуация действительно нормализировалась.
Примем для этого значения порог срабатывания – 5%, при этом условием восстановления будет то, что за 5 минут ни одно значение не превысит этот порог. Теперь, после срабатывания триггера по памяти (штатное значение 90%) он не перейдет в состояние восстановления до тех пор, пока утилизация памяти стабильно не снизится менее 85%.
Для этого в настройках триггера добавим выражение восстановления и запишем туда следующий текст:
max(/Linux by Zabbix agent/vm.memory.utilization,5m) < ({$MEMORY.UTIL.MAX} - 5)Обратите внимание, что здесь мы используем не
min(), а max(), так как у нас ни одно значение метрики не должно в течении 5 минут превысить пороговое. Таким образом мы ввели четкий 5% коридор, который не только предотвращает флаппинг триггера, но и защищает нас от иллюзии ложного восстановления, когда триггер перешел в состояние ОК, но значения остались близки к критическим.
Рекомендуем настроить подобный гистерезис для всех триггеров, имеющих критическое значение для системы, где мы должны быть твердо уверенны, что проблема действительно ушла, а не затаилась на время.
👍28🤮2❤1🤔1👌1
CrowdSec – как система предотвращения вторжений (IPS)
CrowdSec – это популярное ПО с открытым кодом для предотвращения вторжений, многие считают его современным аналогом Fail2ban, однако это не совсем так.
Также сразу внесем ясность: ни Fail2ban, ни CrowdSec не являются средствами защиты от атак на отказ в обслуживании – DDoS, так как являются достаточно ресурсоемкими приложениями и способны в таком сценарии еще сильнее нагрузить сервер.
Но такая задача и не преследуется, данное ПО предназначено для защиты от вторжений: перебора паролей, взлома, проактивного анализа, эксплуатации уязвимостей.
Так чем не угодил Fail2ban, не считая, что CrowdSec стильный, модный, молодежный, весь из себя модульный, написан на Go и содержит встроенный дашборд и мониторинг.
Ключевое различие в подходе к обеспечению безопасности. Fail2ban прост, но в своей простоте он застыл на уровне 15-20 летней давности. Не учитывая современных подходов и сценариев.
Схему работы Fail2ban можно представить в упрощенном виде так:
Основной источник событий – это регулярные выражения, которые получают из лога нужные события, например, неудачная попытка ввода пароля. Затем идет простейший счетчик и, если событие повторилось 5 раз за 10 минут источник события улетает в бан.
Просто и незамысловато. Но это работало 15 лет назад, сейчас же интернет кишит умными ботами, которые один раз попав под бан вычисляют его временные параметры и продолжают свое дело так, чтобы не попадать в фильтры.
CrowdSec предлагает принципиально иную схему, хотя во многом она похожа на предшественника:
Здесь не просто по Regex выделяются нужные строки лога, а выделяются значимые события, которые потом не просто изменяют счетчик, а передаются на сценарный анализ.
Сценарий – это не только ответ на вопрос: что произошло, но и попытка определить, чтобы это могло значить. Сценарий содержит основные паттерны атак и если событие ложится в паттерн, то это одно, а если выбивается из него – то совсем другое, хотя это может быть одно и тоже событие.
Для примера: пользователь забыл пароль и неспеша подбирает его, скажем одна попытка через разные промежутки времени. Четыре неудачных и потом вспомнил, вошел. Потом запускает другой клиент и там автоматически подставился старый пароль.
Fail2ban однозначно отправит пользователя в бан. CrowdSec, при наличии грамотно написанного сценария, во-первых, учтет, что вход похож на подбор пароля человеком, не ботом, а по факту удачного входа сбросит прошлые неудачные попытки.
Если говорить грубо, то принципиальная разница в том, что Fail2ban просто считает ошибки, а CrowdSec пытается понять поведение.
Но за все надо платить. Бытует мнение, что так как Fail2ban написан на Python, а CrowdSec на Go – последний быстрее и менее ресурсоемкий. Однако это не так.
Fail2ban большую часть времени, пока парсер не выдал новое событие может находиться в состоянии покоя и ничего не делать, тогда как CrowdSec постоянно анализирует поведение на соответствие сценариям, т.е. работает фактически непрерывно.
Говорит ли это о том, что Fail2ban устарел? И, да и нет. Если вам нужно что-то простое и незамысловатое – выбор за старым добрым Fail2ban. Но это защита реактивная, которая сработает уже по факту.
Если же вы начинаете новый проект и нуждаетесь в проактивной защите, которая отсечет злоумышленника еще до, то обратите внимание на CrowdSec.
CrowdSec – это популярное ПО с открытым кодом для предотвращения вторжений, многие считают его современным аналогом Fail2ban, однако это не совсем так.
Также сразу внесем ясность: ни Fail2ban, ни CrowdSec не являются средствами защиты от атак на отказ в обслуживании – DDoS, так как являются достаточно ресурсоемкими приложениями и способны в таком сценарии еще сильнее нагрузить сервер.
Но такая задача и не преследуется, данное ПО предназначено для защиты от вторжений: перебора паролей, взлома, проактивного анализа, эксплуатации уязвимостей.
Так чем не угодил Fail2ban, не считая, что CrowdSec стильный, модный, молодежный, весь из себя модульный, написан на Go и содержит встроенный дашборд и мониторинг.
Ключевое различие в подходе к обеспечению безопасности. Fail2ban прост, но в своей простоте он застыл на уровне 15-20 летней давности. Не учитывая современных подходов и сценариев.
Схему работы Fail2ban можно представить в упрощенном виде так:
Лог → Парсинг/Regex → Решение → Действие
Основной источник событий – это регулярные выражения, которые получают из лога нужные события, например, неудачная попытка ввода пароля. Затем идет простейший счетчик и, если событие повторилось 5 раз за 10 минут источник события улетает в бан.
Просто и незамысловато. Но это работало 15 лет назад, сейчас же интернет кишит умными ботами, которые один раз попав под бан вычисляют его временные параметры и продолжают свое дело так, чтобы не попадать в фильтры.
CrowdSec предлагает принципиально иную схему, хотя во многом она похожа на предшественника:
Лог → Парсер → Событие → Сценарий → Решение → Действие
Здесь не просто по Regex выделяются нужные строки лога, а выделяются значимые события, которые потом не просто изменяют счетчик, а передаются на сценарный анализ.
Сценарий – это не только ответ на вопрос: что произошло, но и попытка определить, чтобы это могло значить. Сценарий содержит основные паттерны атак и если событие ложится в паттерн, то это одно, а если выбивается из него – то совсем другое, хотя это может быть одно и тоже событие.
Для примера: пользователь забыл пароль и неспеша подбирает его, скажем одна попытка через разные промежутки времени. Четыре неудачных и потом вспомнил, вошел. Потом запускает другой клиент и там автоматически подставился старый пароль.
Fail2ban однозначно отправит пользователя в бан. CrowdSec, при наличии грамотно написанного сценария, во-первых, учтет, что вход похож на подбор пароля человеком, не ботом, а по факту удачного входа сбросит прошлые неудачные попытки.
Если говорить грубо, то принципиальная разница в том, что Fail2ban просто считает ошибки, а CrowdSec пытается понять поведение.
Но за все надо платить. Бытует мнение, что так как Fail2ban написан на Python, а CrowdSec на Go – последний быстрее и менее ресурсоемкий. Однако это не так.
Fail2ban большую часть времени, пока парсер не выдал новое событие может находиться в состоянии покоя и ничего не делать, тогда как CrowdSec постоянно анализирует поведение на соответствие сценариям, т.е. работает фактически непрерывно.
Говорит ли это о том, что Fail2ban устарел? И, да и нет. Если вам нужно что-то простое и незамысловатое – выбор за старым добрым Fail2ban. Но это защита реактивная, которая сработает уже по факту.
Если же вы начинаете новый проект и нуждаетесь в проактивной защите, которая отсечет злоумышленника еще до, то обратите внимание на CrowdSec.
1👍32❤2🍌1
Завоздушило, так завоздушило…
Решили мы тут с сыном посмотреть новый интерфейс 1С:Предприятие 8.5, которые позиционируется как «воздушный». Для ознакомления взяли небольшую, полностью самописную конфигурацию, которую он в прошлом году написал в качестве школьного проекта.
Конфигурация для учета домашних финансов и проста как мычание: приход, расход, перемещение, учет по кошелькам и статьям расходов/доходов. Никаких сложных форм, все очень просто, что тут может пойти не так?
Для конвертации форм мы воспользовались встроенным инструментом в разделе Рефакторинг, который много чего исправил и оптимизировал. При этом мы надеялись, что официальный инструмент покажет нам как правильно, как это задумано самой 1С.
На первом скриншоте показано как было. Основная страница представляла собой журнал операций и список кошельков с балансом в каждом из них, между частями формы есть видимая граница, которую мы можем перемещать, например, сделав журнал по шире.
Табличная часть журнала при этом автоматом масштабируется, но даже в начальном виде никаких вопросов нет, вся информация прекрасно помещается по ширине, еще и места хватает.
А что мы видим в конвертированной конфигурации? При том же размере окна форма не поместилась по вертикали и у нас возникла вертикальная прокрутка, а откуда она возникла?
Смотрим на таблицу – это полное фиаско, таблица обрезана как по горизонтали, так и по вертикали, потому что не поместилась, а чтобы добраться до горизонтальной прокрутки таблицы нам нужно прокрутить вниз саму форму.
Вообще-то, всю жизнь было принято вписывать таблицу в видимую часть формы и добавлять в нее полосы прокрутки, доступные без скролла страницы. Зачем здесь сделано такое поведение – непонятно.
Ладно, если у нас не хватает места по горизонтали, давайте свернем левое меню и жизнь наладится. Свернули. И что??? И ничего, таблице как было плохо, так и осталось, зато справа появилось пустое место, которое мы никак использовать не можем.
Не лучше выглядят и документы. В старом интерфейсе Такси была другая беда – по умолчанию таблицу растягивало на всю форму, что в случае простых табличек, как у нас, смотрелось не очень. Но все равно таблица четко визуально выделялась, как и итог справа внизу.
Новая форма показала принципиально иной подход, таблица скукожилась по горизонтали, хотя ее шапка по-прежнему занимает почти всю ширину формы и там у нас всегда будет пустое место, если мы, конечно не растянем таблицу руками.
Визуального выделения таблицы у нас нет и итоги просто потерялись, так как невозможно сразу понять, что это за цифра внизу и зачем она там, особенно если таблица маленькая.
Откроем другой документ, точно с такой же структурой и что это??? Что??? Откуда в табличной части взялась горизонтальная прокрутка, если справа еще полно свободного места???
А документ перемещения вообще по высоте не поместился, предлагая нам его скроллить, хотя в исходной форме того же размера мы могли по вертикали поместить содержимое документа два раза.
И вообще, новый интерфейс показывает жуткий дефицит свободного места, особенно по вертикали, хотя в Такси его было с избытком. И если у нас не помещаются уже простые формы, то что говорить о сложных документах?
С таким подходом у нас даже шапка без вертикального скролла не поместится, не говоря уже о табличных частях, где содержится основная информация. А это, если кто забыл, учетная система, а не приложение для домохозяек с двумя большими кнопками.
Учитывая то, что основное разрешение рабочих мониторов – это FullHD, то работать с «воздушными» формами будет сущим мучением, вы же не думаете, что работодатели сразу побегут покупать 2K или 4K мониторы, на которых «воздушным» формам места уже хватает.
Пока все это выглядит как крайне сырой прототип и был бы это действительно прототип – вопросов бы не было, но на интерфейс 8.5 уже переводят рабочие конфигурации (пока только УНФ 3.0 и Розница 3.0), причем в безальтернативном варианте.
Решили мы тут с сыном посмотреть новый интерфейс 1С:Предприятие 8.5, которые позиционируется как «воздушный». Для ознакомления взяли небольшую, полностью самописную конфигурацию, которую он в прошлом году написал в качестве школьного проекта.
Конфигурация для учета домашних финансов и проста как мычание: приход, расход, перемещение, учет по кошелькам и статьям расходов/доходов. Никаких сложных форм, все очень просто, что тут может пойти не так?
Для конвертации форм мы воспользовались встроенным инструментом в разделе Рефакторинг, который много чего исправил и оптимизировал. При этом мы надеялись, что официальный инструмент покажет нам как правильно, как это задумано самой 1С.
На первом скриншоте показано как было. Основная страница представляла собой журнал операций и список кошельков с балансом в каждом из них, между частями формы есть видимая граница, которую мы можем перемещать, например, сделав журнал по шире.
Табличная часть журнала при этом автоматом масштабируется, но даже в начальном виде никаких вопросов нет, вся информация прекрасно помещается по ширине, еще и места хватает.
А что мы видим в конвертированной конфигурации? При том же размере окна форма не поместилась по вертикали и у нас возникла вертикальная прокрутка, а откуда она возникла?
Смотрим на таблицу – это полное фиаско, таблица обрезана как по горизонтали, так и по вертикали, потому что не поместилась, а чтобы добраться до горизонтальной прокрутки таблицы нам нужно прокрутить вниз саму форму.
Вообще-то, всю жизнь было принято вписывать таблицу в видимую часть формы и добавлять в нее полосы прокрутки, доступные без скролла страницы. Зачем здесь сделано такое поведение – непонятно.
Ладно, если у нас не хватает места по горизонтали, давайте свернем левое меню и жизнь наладится. Свернули. И что??? И ничего, таблице как было плохо, так и осталось, зато справа появилось пустое место, которое мы никак использовать не можем.
Не лучше выглядят и документы. В старом интерфейсе Такси была другая беда – по умолчанию таблицу растягивало на всю форму, что в случае простых табличек, как у нас, смотрелось не очень. Но все равно таблица четко визуально выделялась, как и итог справа внизу.
Новая форма показала принципиально иной подход, таблица скукожилась по горизонтали, хотя ее шапка по-прежнему занимает почти всю ширину формы и там у нас всегда будет пустое место, если мы, конечно не растянем таблицу руками.
Визуального выделения таблицы у нас нет и итоги просто потерялись, так как невозможно сразу понять, что это за цифра внизу и зачем она там, особенно если таблица маленькая.
Откроем другой документ, точно с такой же структурой и что это??? Что??? Откуда в табличной части взялась горизонтальная прокрутка, если справа еще полно свободного места???
А документ перемещения вообще по высоте не поместился, предлагая нам его скроллить, хотя в исходной форме того же размера мы могли по вертикали поместить содержимое документа два раза.
И вообще, новый интерфейс показывает жуткий дефицит свободного места, особенно по вертикали, хотя в Такси его было с избытком. И если у нас не помещаются уже простые формы, то что говорить о сложных документах?
С таким подходом у нас даже шапка без вертикального скролла не поместится, не говоря уже о табличных частях, где содержится основная информация. А это, если кто забыл, учетная система, а не приложение для домохозяек с двумя большими кнопками.
Учитывая то, что основное разрешение рабочих мониторов – это FullHD, то работать с «воздушными» формами будет сущим мучением, вы же не думаете, что работодатели сразу побегут покупать 2K или 4K мониторы, на которых «воздушным» формам места уже хватает.
Пока все это выглядит как крайне сырой прототип и был бы это действительно прототип – вопросов бы не было, но на интерфейс 8.5 уже переводят рабочие конфигурации (пока только УНФ 3.0 и Розница 3.0), причем в безальтернативном варианте.
🤣27🤮7🤔5❤2💯2
Что такое современная платформа 1С:Предприятие и нужно ли ее знать администраторам
До сих пор замечаем со стороны коллег пренебрежительное отношение к 1С:Предприятие и нежелание изучать эту платформу или вообще касаться ее. Мол есть «одинэсники» — вот пусть они и занимаются, а мы «тру админы» и у нас другие задачи.
Но позиция эта в корне неправильная и ниже мы постараемся пояснить почему. А начнем с того, что нравится это кому-то или нет, но именно 1С:Предприятие сегодня является стандартом учетной системы де-факто.
И надо сказать, что на свои лидирующие позиции фирма 1С вышла сама, в достаточно жесткой конкурентной борьбе, кто застал конец 90-х и начало нулевых – тот помнит существовавший зоопарк на рынке учетного ПО.
Так чем же 1С:Предприятие сумело привлечь к себе пользователей на фоне многочисленных конкурентов? А тем, что 1С была и есть открытая система – исходный код конфигураций открыт и доступен для свободной доработки любому пользователю, правомерно владеющему системой.
И этот момент трудно переоценить, учет – это такая тонкая вещь, которая вроде и одинаковая, но не совсем. Бизнес-процессы везде разные и владельцам бизнеса закономерно хочется, чтобы программа как-то учитывала их особенности.
1С:Предприятие, как и другие учетные системы – товар коробочный, массовый и отражает некоторый средний бизнес в вакууме. Да, можно сказать, мол адаптируйте свои бизнес-процессы под программу, но бизнес – это не про то, как красиво и правильно, а про то, как заработать денег.
В 1С код конфигурации открыт, и любой пользователь может свободно адаптировать типовое решение под нужды своего бизнеса, а если вы не готовы столь глубоко лезть в систему, то к вашим услугам внешние отчеты и обработки, которые помогут получить нужные данные или выполнить некоторые действия.
Именно это стало киллер-фичей, теперь любой бизнесмен знал, что, покупая коробку с 1С:Предприятие он получает не только типовой функционал, но и возможность допилить решение именно под особенности своего бизнеса и именно так, как нужно ему, а не как видит разработчик.
Вместе с этим росла и сама платформа 1С:Предприятие, начиная с небольших файловых баз в формате DBF платформа превратилась сегодня в полноценное клиент-серверное приложение с широкими возможностями.
Не забыто и сетевое взаимодействие, сегодня для интеграции с внешними системами 1С:Предприятие предлагает Web и HTTP (REST) интерфейсы, Odata, работу через веб-сервер, мобильные приложения.
Да, проблемы у платформы 1С:Предприятие есть, их много, но это не повод к отрицанию, потому что реального конкурента у 1С сегодня нет. Именно как платформы уровня предприятия.
Есть много онлайн-сервисов, типа «Моя Бухгалтерия» и т.п., но по мере роста бизнеса их пользователи неизбежно приходят к вопросу: а как нам отсюда перейти на 1С?
А причем здесь системный администратор? А при том, что 1С сегодня, это не какое-то там приложение на компьютере в бухгалтерии, а полноценная клиент-серверная система.
Это и сам сервер 1С:Предприятие, и СУБД, и веб-сервисы, многие не в единственном экземпляре и обслуживать все это хозяйство будет именно системный администратор.
Но 1С:Предприятие, как и любая иная система, имеет свои особенности и не понимая их трудно добиться стабильной и производительной работы системы. Спихнуть проблему на другую сторону тоже не получится.
Мир 1С:Предприятие уже вполне взрослый и сформировавшийся, со своими ролями и профессиями. И программист 1С не будет разбираться почему у вас там тормозит, это не его задача и не его проблема.
А 1С:Предприяитие сейчас, это как минимум контур Бухгалтерия + Зарплата и там есть крайне чувствительные моменты, скажем как сроки сдачи отчетности. За ее срыв никого по голове не погладят.
Поэтому следует признать, что 1С:Предприятие – это один из стандартов, который уважающий себя специалист обязан знать хотя бы на базовом уровне.
До сих пор замечаем со стороны коллег пренебрежительное отношение к 1С:Предприятие и нежелание изучать эту платформу или вообще касаться ее. Мол есть «одинэсники» — вот пусть они и занимаются, а мы «тру админы» и у нас другие задачи.
Но позиция эта в корне неправильная и ниже мы постараемся пояснить почему. А начнем с того, что нравится это кому-то или нет, но именно 1С:Предприятие сегодня является стандартом учетной системы де-факто.
И надо сказать, что на свои лидирующие позиции фирма 1С вышла сама, в достаточно жесткой конкурентной борьбе, кто застал конец 90-х и начало нулевых – тот помнит существовавший зоопарк на рынке учетного ПО.
Так чем же 1С:Предприятие сумело привлечь к себе пользователей на фоне многочисленных конкурентов? А тем, что 1С была и есть открытая система – исходный код конфигураций открыт и доступен для свободной доработки любому пользователю, правомерно владеющему системой.
И этот момент трудно переоценить, учет – это такая тонкая вещь, которая вроде и одинаковая, но не совсем. Бизнес-процессы везде разные и владельцам бизнеса закономерно хочется, чтобы программа как-то учитывала их особенности.
1С:Предприятие, как и другие учетные системы – товар коробочный, массовый и отражает некоторый средний бизнес в вакууме. Да, можно сказать, мол адаптируйте свои бизнес-процессы под программу, но бизнес – это не про то, как красиво и правильно, а про то, как заработать денег.
В 1С код конфигурации открыт, и любой пользователь может свободно адаптировать типовое решение под нужды своего бизнеса, а если вы не готовы столь глубоко лезть в систему, то к вашим услугам внешние отчеты и обработки, которые помогут получить нужные данные или выполнить некоторые действия.
Именно это стало киллер-фичей, теперь любой бизнесмен знал, что, покупая коробку с 1С:Предприятие он получает не только типовой функционал, но и возможность допилить решение именно под особенности своего бизнеса и именно так, как нужно ему, а не как видит разработчик.
Вместе с этим росла и сама платформа 1С:Предприятие, начиная с небольших файловых баз в формате DBF платформа превратилась сегодня в полноценное клиент-серверное приложение с широкими возможностями.
Не забыто и сетевое взаимодействие, сегодня для интеграции с внешними системами 1С:Предприятие предлагает Web и HTTP (REST) интерфейсы, Odata, работу через веб-сервер, мобильные приложения.
Да, проблемы у платформы 1С:Предприятие есть, их много, но это не повод к отрицанию, потому что реального конкурента у 1С сегодня нет. Именно как платформы уровня предприятия.
Есть много онлайн-сервисов, типа «Моя Бухгалтерия» и т.п., но по мере роста бизнеса их пользователи неизбежно приходят к вопросу: а как нам отсюда перейти на 1С?
А причем здесь системный администратор? А при том, что 1С сегодня, это не какое-то там приложение на компьютере в бухгалтерии, а полноценная клиент-серверная система.
Это и сам сервер 1С:Предприятие, и СУБД, и веб-сервисы, многие не в единственном экземпляре и обслуживать все это хозяйство будет именно системный администратор.
Но 1С:Предприятие, как и любая иная система, имеет свои особенности и не понимая их трудно добиться стабильной и производительной работы системы. Спихнуть проблему на другую сторону тоже не получится.
Мир 1С:Предприятие уже вполне взрослый и сформировавшийся, со своими ролями и профессиями. И программист 1С не будет разбираться почему у вас там тормозит, это не его задача и не его проблема.
А 1С:Предприяитие сейчас, это как минимум контур Бухгалтерия + Зарплата и там есть крайне чувствительные моменты, скажем как сроки сдачи отчетности. За ее срыв никого по голове не погладят.
Поэтому следует признать, что 1С:Предприятие – это один из стандартов, который уважающий себя специалист обязан знать хотя бы на базовом уровне.
2👍32🤡8❤4💯4🤝2