— Итак, ситуация. – начал Сергей. – У нас несколько пользователей, бухгалтеров. У всех – полные права. И кто-то из них, вероятно, нам гадит в учете. Что делать?
— Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?
— За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.
— А, точно… — не стал спорить Стас. – Ну, и что?
— А то, что перед нами классическая дыра в заборе. – многозначительно поднял вверх указательный палец Сергей.
— Мать честная… — улыбнулся Стас. – Классическая дыра в заборе! Это в каком же трактате написано про классическую дыру в заборе?
— Сейчас мы с тобой этот трактат напишем. Усаживайся поудобнее.
— Я весь внимание. – кивнул Стас.
— Представь ситуацию. Завод, окружен забором. Ну, из сетки, как она там называется… Из проволоки такая…
— Сетка рабица. – подсказал Стас.
— Да, наверное. И вот в этом заборе обнаружили дыру. Что делать?
— Погоди, ты сейчас фантазируешь? – спросил Стас. – Или реальную историю рассказываешь?
— Ну, вообще, реальную. – нахмурился Сергей. – А что?
— Вот ум программистский. – засмеялся Стас. – Нет чтобы просто историю рассказать, он будет ее абстрагировать, обобщать и превращать в некое знание.
— Ладно. – улыбнулся в ответ Сергей. – Короче, это мне тесть рассказал. Он начальником завода работает. Не суть. В общем, нашли они дыру в заборе. Что с ней делать?
— Хм… Может, залатать? – Стас изобразил искреннее рвение.
— Залатать-то можно, только как ты узнаешь, кто через эту дыру шастает? – Сергей не обратил внимания на сарказм друга. – Заделаешь одну дыру, появится новая. Только и будешь бегать и дыры латать.
— А, вон ты про что… — сконфузился Стас. – Ладно, давай дальше рассказывай.
— Они сделали засаду. Сначала хотели камеру поставить, потом подумали – нафига. Мероприятие-то на несколько дней всего, потом камера не нужна будет, все равно дыру заделывать.
— Засада – это самое оно. – покивал головой Стас. – Я сериал про полицию смотрел, они там тоже так делали.
— Так вот. Там, неподалеку от этой дыры, был сарайчик с инструментом – ну там, грабли, лопаты и так далее, для ребят, которые уборкой территории занимаются.
— Уборкой территории? На заводе? – удивился Стас. – Я думал, там только субботники территорию убирают.
— Не, у меня тесть порядок любит. – улыбнулся Сергей. – Как стал начальником завода, такой марафет навел, загляденье. Все, не отвлекай.
— Окэ, давай дальше.
— Посадили в засаду охранника и, вроде, даже начальника охраны. Чтоб попредставительнее было. Указание было такое: как кто в дыру полезет, ловить и тащить на допрос.
— О, такое было в фильме, как его… «Турецкий гамбит». – опять влез Стас. – Помнишь? Они там слух пустили, что секретное оружие есть в армии, и засаду посадили. Хотели поймать того, кто полезет смотреть.
— Поймали?
— Не, не поймали. Но побегали изрядно, удовольствие получили.
— Ну ясно. А тут – поймали. – Сергей многозначительно замолчал.
— Ну, и что? – нетерпеливо спросил Стас. – Кого поймали?
— Чувака какого-то. Дело было поздно вечером уже. Идет, щемится, в руках сумка. Поймали, говорят – пройдемте, уважаемый. Ну и под белы рученьки, как говорится, в допросную.
— А в сумке что?
— Смеяться будешь. – сказал Сергей и улыбнулся.
— Ну давай, не томи.
— Пять освежителей воздуха и три рулона туалетной бумаги. – засмеялся Сергей.
— Твою ж мать. – засмеялся Стас. – Во попадалово. Ладно б там лом, или запчасти, а то туалетная бумага.
— Ну, валенок какой-то. – сквозь смех сказал Сергей. – Ходил, собирал по туалетам, и таскал домой.
— Нафига ему столько освежителей? Вместо дезодорантов что ли использовать?
— Нафига, не нафига… Шоб було.
— Вот дебил… И что, чем кончилось?
— Чем-чем, уволили к чертям собачьим. Разнорабочий оказался, не ценный сотрудник.
— Еще кого-то поймали? – Стас уже прекратил смеяться.
— Да, так, по мелочи. Перед обедом тетка какая-то хотела вылезти. Сказала, что ребенка на тренировку надо отвести, там в 11 часов начало, а обед – в 12. Начальник не отпускает, вот она и бегает через дыру, чтобы не КПП не отмечаться.
— Тоже уволили?
— Не, тесть сказал – хорошая тетка, давно работает, он ее давно знает, еще когда сам в цехе работал. Поговорил с ее начальником, велел отпускать, просто обед ей сдвинули. Ну, ребенка отводит, потом дома обедает, и к 12 часам возвращается. Она прям рада была.
— И все? Или еще кого поймали?
— Больше не стали, залатали дыру и велели охране ежедневный обход забора делать.
— Понятно, ладно. – покивал Стас. – Нам-то это чем поможет? Тоже засаду на бухгалтерию устроим?
— Ну да. Возвращаемся к нашей ситуации. Есть дыра – полные права у всех.
— Вообще, странная дыра, конечно… — задумался Стас. – Наверное, только у нас такое.
— Не, не только у нас. – помотал головой Сергей. – Я когда в компании-интеграторе работал, часто такое видел. Особенно, когда контора небольшая и программиста нет. Просто просят всем полные права дать, чтобы работа колом не вставала, если что-то не получится. И вообще, не перебивай.
— Все, молчу. – Стас примирительно поднял ладони.
— Наша цель – понять, кто гадит в учете. Например, меняет движения по складу за прошлый месяц, или там за прошлый квартал. Если просто забрать у всех права, и поставить одинаковый уровень доступа, то получим очередной скандал. А главное – ничего не узнаем. Поэтому сядем в засаде.
— Так, это уже интереснее. – не выдержал Стас. – Давай, давай, рассказывай.
— А чего рассказывать… — пожал плечами Сергей. – Все просто. Первое – надо добавить возможность изменения прав на лету. Ну, чтобы можно было за пару секунд забрать, и наоборот – дать. Без перезапуска программы у пользователя.
— Понял, это несложно.
— Да, несложно. Сегодня сделаем. Дальше. Делаем права точечными, максимально точечными.
— Это как?
— Раз речь о складе, то так: назначаем индивидуально на каждый склад, и каждый вид операции. Они же не все подряд делают все операции? Одна делает отгрузки, другая – поступления, и так далее. Вот и мы такую настройку обеспечим.
— А по складам зачем делить? – нахмурился Стас.
— Затем, что у них и по складам ответственность делится. – терпеливо объяснял Сергей. – Одна работает, например, с цеховыми складами, другая – нет. А сейчас, пока настройка не точечная, мы понятия не имеем, кто с каким складом что делает.
— А, теперь понятно.
— Ну все. Главное – чтобы можно было на лету менять. Начала она документ делать, раз – нет прав. Она сразу жаловаться. Если мы быстро дадим права, и она просто доделает документ – отлично, скандала не будет.
— Во, а мы как решать будем, кому давать, а кому нет?
— Маленький допрос устроим – кто такой, то есть кто такая, чего делаешь, нафига, почему именно ты, а не вон та прелестная девушка, ну и так далее.
— Так скандалить начнут все равно. – покачал головой Стас. – В чем смысл-то?
— А мы бумажку какую-нибудь сделаем, и у Курчатова подпишем. Типа ревизия прав доступа. Раз ты упомянул «Турецкий гамбит», помнишь там бумажка была? Всякий подданный, всякого звания, обязан оказывать подателю сего полное и безусловное содействие.
— Так если будет такая бумажка, нам и городить ничего не надо. – улыбнулся Стас. – Просто скажем им, прикрикнем, прикажем – делайте вот так. Ты – отгрузки, ты – перемещения, ну и так далее.
— И получим очередной год, в котором не решена проблема склада.
— Да почему? – всплеснул руками Стас.
— Да потому, что это типичный подход эффективного менеджера – получить бумажку, карт-бланш, и начать раздавать приказы налево и направо. Не разбираясь в системе, связях, процессах.
— А, ты опять про свое системное мышление… — скис Стас.
— Опять, а что такого?
— Да так я…
— Чего так, Стас? Ты что, думаешь, мы тут в игрушки играем?
— Да нет, конечно. Просто как-то это… Не по-настоящему, что ли. Вроде все понятно, теория красивая, а как работать – непонятно.
— Смысл не в теории, а в ее применении. – немного агрессивно ответил Сергей. – Теорию все знают, а толку-то? Вот Курчатов наверняка читал системное мышление, и еще кучу умных книжек. Видел же полку с книгами в коридоре?
— Как будто он их все читал…
— Все читал! Ты не знал, что ли? Он постоянно покупает и читает книги всякие, для бизнеса. Потом ставит на полку, чтобы остальные читали. Не знаю, берет кто-то или нет, но сам-то Курчатов читал. И где он?
— Не знаю, у себя в кабинете вроде. Или в аэропорту, он вроде в Германию собирался.
— Его нет здесь. Не в нашем кабинете, а в проекте. Потому что он не знает, что делать. Теорию знает – попроси рассказать, например, про системы, он красиво и убедительно тебе все по полочкам разложит. А как применить эти знания – не знает.
— Почему?
— Потому, что он не инженер, а менеджер.
— А инженеры тут причем вообще?
— При том, что изучение методов и их применение – работа инженера. Понимаешь? Вот ты же изучаешь новые технологии?
— Ну… — потянул Стас и улыбнулся.
— Да изучаешь, я знаю. Когда с чем-то новым сталкиваешься, задачей там необычной, или еще чем. Что делаешь?
— Раскуриваю, мануалы читаю, практику, статьи.
— Вот! Не просто так читаешь, для академического интереса, а для дела! Тебе надо применить метод, и ты изучаешь, как это сделать можно. Пробуешь, смотришь, что получится, меняешь, если не пошло, и так далее.
— А они – не так, что ли? – удивился Стас.
— Не так, в том-то и дело! У них потоки теории и практики не пересекаются, каждый живет своей жизнью. Ну, знаешь, как у преподов в институте. Смотришь – вроде все знает, электронику, например, а если вытащить на завод – в лужу сядет.
— Так уж и сядет…
— Не все конечно, бывают толковые преподы, с большой практикой, но есть и откровенные бездари. Мне препод, у которого я диплом делал, как-то сказал такую шутку: не умеешь работать – иди в преподаватели.
Даже случай один был. Двое парней делали диломный проект, на заводе. Сделали какую-то штуку, не помню точно, ну девайс короче, электронный, для производства. Не просто спроектировали, а собрали, применили, и вполне удачно, даже вроде запатентовали.
А потом – защита диплома. И там, в комиссии, сидит вот такой вот чудо-препод, гений электроники – посмотрел на схему, на описание работы, да как психанет – это, говорит, не будет работать! Ему патент показывают, отзыв с завода – ни в какую! Не будет, говорит, и все! Да уперся, как баран, ему и преподы другие, и председатель комиссии говорят – разуй шары, дебил! В итоге из-за него парни четверку получили.
— Мда… — задумчиво пробормотал Стас.
— То же самое с эффективными менеджерами, один в один почти. Знают много, рассказать могут, на семинаре выступить, некоторые даже консультантами подрабатывают. Любую теорию тебе красиво изложат, статью напишут, а как до дела дойдет – пфффф.
Сделать ничего не могут, только приказы раздавать налево и направо. Внедрить 5S! Внедрить Lean! Внедрить CRM! Применить методы системного мышления!
При том, что, по сути, они сами – инженеры бизнеса. Ну, должны ими быть. Бизнес ведь – тоже система, понимаешь? Какая к чертям разница, как система реализована физически? Вот ты программный код пишешь, формы рисуешь – получается система.
Менеджер, когда организует, например, новый отдел – тоже систему строит. Ну там, поставил стол, стул, человека посадил, компьютер поставил, инструкцию написал, процесс и так далее. Все, система!
— Ну, а что не так-то? – непонимающе покачал головой Стас. – Вот и сделал он систему.
— Да не систему он сделал, а коробку развернул! – раздраженно ответил Сергей. – Как конструктор сайтов, я не знаю. Или коробочную информационную систему. Или бизнес по франшизе. Он вообще не понимает, как это все работает. Фурычит как-то, и все. А если не фурычит – надо просто заорать погромче. Или людей уволить, даже если они ни в чем не виноваты.
Понимаешь? Вот ты сделал систему – информационную. Можешь поступать, как программист из анекдотов – работает, и все, не трогайте ничего. А потом – бац! – и перестает какой-то кусок у тебя работать. Ну, или, проблемы с производительностью начинаются, например. Что делать будешь?
— Запущу отладку с замером производительности. – кивнул Стас.
— Да, запустишь, найдешь узкое место, и попытаешься понять, что там не так. Например, запрос кривой у тебя, выполняется полминуты, а должен – полсекунды. Что делать будешь?
— Поменяю его, рефакторинг сделаю.
— А менеджер на него наорет! На запрос! – агрессивно сказал Сергей. Стас в ответ улыбнулся, и агрессию Сергея как рукой сняло.
— Твою мать, ну и аналогии у тебя… — смеялся Стас.
— Так оно и есть! – ответил Сергей. – Или уволит запрос. Или другой запрос вместо него поставит. Или расскажет запросу, что тот – мудак, не любит компанию, ведет себя отвратительно, и вообще, почему одет не по форме?
— Блин, тоже верно. – Стас уже не мог остановиться. – Или поговорит по душам с запросом, по какой-нибудь методике, типа Дейла Карнеги.
— Ага, точно. Но это – только в том случае, если он хоть чего-то умеет. Целенаправленно врать – это ж уже осознанное.
— А, ну да…
— А поделать он ничего не может. Точнее – не хочет. Хотя все методы знает, если он – эффективный менеджер. Потому что двуликий, как Янус. Или, как говорят в деревне, ни рыба, ни мясо. То ли боится, то ли лодку раскачивать не хочет. Максимум – поручит кому-то из подчиненных, а сам будет поглядывать, советы свои долбаные давать.
— Как Курчатов тебе поручил? – хитро прищурился Стас.
— Ну да… — осекся Сергей. – Точно, блин! Так он в первый раз правильно поступил! Понимаешь? Раньше ведь он кому поручал?
— Главбуху, еще кому-то…
— Вот! Менеджерам опять же! И у них ничего не получилось! А мы с тобой – инженеры, и у нас получится!
— Ну, не у нас, а у тебя. – поправил Стас.
— Да не придирайся к словам. – махнул рукой Сергей. – Мы с тобой историю творим! Если получится со складом… Точнее – когда получится со складом, поймет Курчатов, кому надо поручать наведение порядка, понимаешь? Кто должен изменения в системе делать?
— Инженеры. – картинно кивнул Стас.
— Инженеры! Правильно! – воскликнул Сергей. – А эффективные менеджеры – это просто пользователи системы, пусть и с руководящими полномочиями. Ну, как заказчики доработок информационной системы. Вроде как они – владельцы своей части программы, но при этом изменить в ней ничего не могут. Обращаются к кому?
— К нам, программистам.
— Да, к нам. Мы вносим изменения, они продолжают пользоваться. Почему так же не делать с остальными системами? Раз сами не могут, не умеют, не решаются, будем мы изменения делать! Нам не нужны полномочия, власть, понимаешь? Мы не забираем их хлеб, мы не будем проситься в начальники склада, когда победим его проблемы. Просто починим, и уйдем, дальше в носу ковыряться.
— Звучит заманчиво. – прищурился Стас, как довольный кот. – Отдел изменения бизнес-системы. А руководители – наши пользователи. Дело за малым – навести порядок на складе.
— Да, это само собой. – кивнул Сергей. – Возвращаясь к нашим баранам. Так, ты делаешь систему быстрой настройки прав доступа. Так?
— Так.
— А я пока…
Что там Сергей собрался пока делать, никто не узнал, потому что дверь в кабинет распахнулась, и в нее вошли двое – бухгалтер Даша и кладовщик Рустам.
— Что, опять? – вздохнул Стас.
— Опять! – крикнул Рустам. – Задолбались уже!
— Что там у вас опять? – недоуменно спросил Сергей.
— Да… — махнул рукой Стас. – Давайте сюда свою бумажку.
Комментарии (46)
Eldhenn
13.09.2018 12:25Подумаешь, переписать систему прав доступа…
Подумаешь, поставить весь процесс раком, ведь каждый бух для каждой операции должен будет в IT-отдел на поклон идти…
Подумаешь, после второго-третьего раза это будет отменено с самого верха…AlexTOPMAN
14.09.2018 15:38Как понял я, выдача админских прав на ходу нужна лишь для того, чтобы логировать именно в эти моменты, а не всё подряд. Так выборка будет много репрезентативней, т.к. подавляющее число операций укладываются в типовые права для роли бухгалтера.
tvr
13.09.2018 12:50+1Права дать и индивидуальные пароли для записи новых/изменения старых документов.
Вылазит косяк с какой-нибудь единицей хранения/учёта — смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период. Когда и если источник проблем будет локализован, показательный расстрел и изъятие лишних прав у остальных. Всё на правах ИМХО.
P.S. За цикл статей спасибо, хорошо написано.Mike_soft
13.09.2018 14:12иногда достаточно требовать при записи документа сильно задним числом объяснения, почему этот документ изменяется, кто виноват в несвоевременной актуализации документа, и с кем из руководства это согласовано. после этого список измененых «в глубокой заднице» документов начинает сокращаться…
tvr
13.09.2018 14:39Не, нам же надо отловить, кто через дыру в заборе шастает туда-сюда, а потом уже зададим вопрос отловленным — «А с какой целью, товарищ, вы мимо проходной тропу протоптали?», а вы предлагаете на этой дыре ещё одну проходную поставить поставить.
Mike_soft
13.09.2018 15:01ну вообще, конечная цель — «навести порядок».
выяснять причины, конечно, нужно. без этого не обойтись. но иногда эти причины достаточно субьективные (не успела-забыла-не подумала о последствиях).
и проблемы _предотвращаются_ тем, что пользователь понимает: косяк будет зафиксирован, косяк придется как минимум объяснять, а то и отвечать. И возникает дилемма: косячить по-минимуму, или накосячить и свалить.
stanislavkulikov
13.09.2018 15:55А зачем здесь первый пункт с изменением прав?
смотрим её движения по документам/кто именно в них ковырялся и логи действия именно этого пользователя за этот период
Всё это можно делать и не обрезая права. Точнее даже сказать, что это вообще не связанные вещи: изменение прав и аудит.
stanislavkulikov
13.09.2018 14:23+2Какой-то длинный текст полный глупых идей и нелепых аналогий. Если есть проблемы с конкретными документами и есть логи, то можно просто посмотреть логи по этим документам. А вот с точечными правами мысль вообще не ясна. Зачем? Посмотреть кто работает с проблемным участком? Так опять же это можно увидеть в логах. Если там нет такой информации, то нужен нормальный аудит.
И опять же исходя из этого аналогия вообще не к месту смотрится. Дырка в заборе — это когда у человека нет прав, на то, что бы входить/выходить, но он находит путь в обход системе разделения доступа. А в данном случае все ходят через проходную, но предлагается на этой проходной ворота не открывать, пока человек не скажет куда идёт.fouxer
13.09.2018 15:37Как я понял, сейчас там нет вообще никакого разделения прав
stanislavkulikov
13.09.2018 16:09Нет разделение прав есть, судя по фразам
Есть дыра – полные права у всех.
Просто просят всем полные права дать, чтобы работа колом не вставала, если что-то не получится.
Т.е. просто у всех root права
Насколько я понял нет нормального аудита и его отсутствие хотят заменить точечными правами. Например, проблема с документом 5X-18, а к этому документу имеет права доступа только Катя, значит она и косячит.
В общем, самый что ни на есть костыльный способ решения проблемы.jaddd
14.09.2018 12:39Тут проблема, скорее всего, не в области исполнения прав и обязанностей, а в том что эти права и обязанности не были правильно настроены.
Примеров такой ситуации есть масса:
Кладовщику никто не вменил в обязанности списывать детали в момент отгрузки, он их отмечает скопом в конце недели, когда его никто не беспокоит.
В системе отметок нет, поэтому начальник производства или логист выкручиваются как могут, например могут по косвенным признакам — отгрузка заказа, понять что детали со склада ушли. И они закрывают заказ целиком, автоматически проставляя отметку что детали со склада ушли. Вроде все нормально, но потом окажется, что детали со склада не брали, а так как было срочно, а кладовщика(или деталей) не было — взяли с менее срочного заказа. Но по этому менее срочному заказу детали уже списаны со склада и по текущему получается тоже. А по факту со склада ушел только один комплект, а не два.
На следующей неделе нач.производства приходит за недостающей деталью, а ему кладовщик говорит, что дать еще не может. И вообще по его системе все уже выдано и предлагает нач. производству оформить акт брака на уже выданное и он по нему выдаст недостающий комплект. Нач.производства такое устроит, а вот по документам со склада ушло три комплекта, а по факту два.
Что будет в конце месяца при аудите? Излишек. Но это же в плюс кладовщику, так что его вроде как наказывать не за что. А если выдается очень много деталей то концы найти очень и очень тяжело. А если за кем-нибудь еще и косяк будет, то почти невозможно, так как еще и следы будут скрывать. Только засаду готовить и остается.
Подобных ситуаций может быть масса — а на вопрос кладовщику, какого органа он сразу не списывает. Вполне может лежать ответ в области решений руководства:
-дикий перегруз потому что начальство экономит на фонде ЗП
-невозможно делать физически. Компьютер стоит черти где.
-Кладовщик пришел только 2 месяца назад и ему никто не говорил и никто не требовал этого(без бумажной инструкции и подписи почти непроверяемо)
-Кладовщик ушел в отпуск, вместо него поставили уборщицу бабу Нюру, которая детали все знает, так как работала раньше на предприятии на рабочей должности, но с компьютером совершенно не может работать. И за нее вбивает данные начальник, но раз в несколько дней — как будет свободен и вообще вспомнит про это.
— и т.д. и т.п.
Здесь вопрос в организации и координации. Кто что делает, для чего(какой будет результат), оценены риски и проблемные точки, как именно будут решаться конфликтные и форсмажорные ситуации. Если это прописать тогда уже будет вопрос по правам доступа. А иначе получится автоматизация бардака и борьба с поносом запиранием туалета))))
Ну а после естественно вопрос контроля. Все ли участники системы работают как запланировано.
evmnn
13.09.2018 15:37Подозреваю «дырка в заборе» — это Стас, который бухгалтерам и кладовщикам меняет данные задним числом, потому что «нада».
imanushin
13.09.2018 15:53меняет данные задним числом
А что в этом плохого? Ошибки исправляются, коррекции вносятся.
Далеко не все программы позволяют просто добавить товар на склад, так как в предыдущей операции была ошибка.
А требовать безошибочности от пользователей вообще идиотизм. Тогда народ не работать будет, а документы перепроверять по 100 раз. Это всё равно, что требовать формальной верификации для всех программ, в том числе для косынки.
Отсутствие аудита и истории изменений — вот это плохо.Mike_soft
13.09.2018 16:15плохо то, что данные, уже полученные после даты измененного документа, становятся некорректыми. (естественно, не все — но четкого механизма понимать, что конкретно стало неверным — я не видел). а на основе этих данных были уже приняты управленческие решения.
Требовать безошибочности нельзя. но свести раздолбайство к минимуму — надо стараться.tvr
13.09.2018 16:17Удваиваю. Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.
Eldhenn
13.09.2018 16:47Вообще-то в нормальной бухгалтерии так и делается, и делалось всегда до компьютеров.
imanushin
13.09.2018 19:38Если обнаружена ошибка, её по возможности надо корректировать в текущем периоде, а не править приход/расход 3 квартала назад.
Откуда эти голословные заявления? А если система требует, чтобы выплата по договору и заключение договора происходила с одним предприятием, то что делать для случае, когда права переходят к другому (т.е. Медиа Маркт закрылся, по гарантии отвечает МВидео)? А систему править нельзя, так как внешний вендор не собирается этим заниматься.
Далее: а что если человек оформляет overtime задним числом? Например, в пятницу вечером была запара, в бухгалтению не успели сбегать.
Самое важное: система должна быть для людей, а не для формальностей. git позволяет изменять историю. Да и все остальные системы тоже. И это не просто так.
Mike_soft
14.09.2018 08:04а для каких именно людей?
вот реальный пример: продажникам дали задание срочно слить остатки товара. продадут — премия. они — выполнили. а у бухгалтера «в пятницу была запара», и он «не успел оформить приход». оформил в понедельник. ничего страшного — продажники требуют заработаную приемию, начальство не выдает, потому, что на остатках товар есть — и у конкурентов он появился более дешевый.
Или другой реальный пример: товар был бракованый (у всех региональных дистрибуторов, кстати — чисто производственный брак), списание «решили оформить потом» (оформим задним числом, ничего страшного), а система подтвердил заявку торговой сети на этот товар. как вы догадываетесь, на количество, которое обычно сеть брала у 3 дистрибов. штрафы за недопоставку до 50%…
такие привычные мелочи, как штрафы от налоговой за расхождение в учете, или съехавшую себестоимость, продажи «в ноль» или «в минус» из-за добавления задним числом накладных расходов я и не говорю — рутина…
так для каких именно людей из вышеперечисленного «система должна быть»?imanushin
14.09.2018 12:12Расследование проведено? Ошибка устранена? Товар продан? Если так, то зачем мешать работать? Или вдруг менеджер не знает про строгость бухгалтерской отчетности?
В общем, в вашем примере система отработала как надо. А если люди поняли свою ошибку, то вообще всё классно, бизнес идет. Это лучше, чем отсутствие продаж, так как нет прав добавить документ в файл, а айтишник уже вечером пивко пьет вдали от компа.
Akon32
14.09.2018 09:13git позволяет изменять историю.
Дополню, что git, хоть и позволяет изменять историю, но очень противится этому. Если нужна существенно изменяемая история — лучше использовать что-то другое.
Eldhenn
14.09.2018 12:21Если нужна изменяемая история — нужно ХОРОШО ПОНИМАТЬ, ЧТО ИМЕННО ТЫ ДЕЛАЕШЬ. В гите тоже не рекомендуют менять историю, и совершенно точно настоятельно не рекомендуют менять историю тех коммитов, о которых знает кто-то ещё. Оффтопик — вот если бы гит позволял в одной ветке красивую историю, а в другой полную, при этом начало и конец фрагмента указывали бы в обеих ветках на одинаковые места…
back on topic: ведь правила бухучёта не просто так придумали, и сторнирование, и бухгалтерские справки…
pnetmon
13.09.2018 16:14+2— Может, логи посмотреть? – ехидно спросил Стас. – Логи-то на что?
— За какой период ты собрался логи смотреть? – нисколько не смутился Сергей. – За месяц? Год? Я напомню, проблема со складом длится несколько лет.Они что не могут выпустить отчеты на определенную дату ну бекап древний взять. Потом через время выпустить на эту же дату эти отчеты и сравнить. Все разночтения по остаткам будут видны.
Mike_soft
14.09.2018 07:42можно еще проще — фиксировать критичные остатки в той же базе. хотя бы при закрытии месяца. (лучше, конечно, дня — но к этому торговым организациям приходится идти несколько лет). тогда контроль «съезжания остатков» проверяется практически автоматически, место выявляется с точностью до «периода закрытия», дата изменения — с точностью до периода контроля. оттуда по логам выдергивается автор изменений…
pnetmon
14.09.2018 08:06фиксировать критичные остатки в той же базе
А что воровать по крохи и из-за объема получить существенную сумму нельзя?
Все изменения будут видны сейчас. А не через месяцы притом злоумышленник ляжет временно на дно.
И притом без никаких доработок и длительной раздачи прав. Что конечно правильно, но....
Желание
— Наша цель – понять, кто гадит в учете. Например, меняет движения по складу за прошлый месяц, или там за прошлый квартал.… А главное – ничего не узнаем. Поэтому сядем в засаде.
Дыру в заборе заделали, но вот что не увидели....
Mike_soft
14.09.2018 08:14критичные — я имею ввиду остатки по основному складу, например. От которого зависят много показателей (например, продажи продукции, остатки неликвидов, доплаты кладовщиков при инвентаризации, бонусы закупщиков за нормативность запасов — кроме, собственно стоимости товаров), можно хоть слепок состояния учета делать — вопрос в объемах.
ну и я не столько про воровство (линейные бухгалтера крайне редко воруют), а про искажение учета из-за работы задним числом.
pnetmon
14.09.2018 08:42Да и к правам и логированию.
А вот Х знакома с Y который шантажирует Z который является сотрудником компании W которая дорабатывает эту систему. И Z меняет данные не через оболочку программы, а сразу в базе. Логирование конечно есть, но кто же смотрит логирование V, когда все действия в оболочке программы логируются в ней.
А вот сравнение может выявить и такой случай.
Mike_soft
14.09.2018 09:21абсолютно согласен. в этом случае сравнение с сохраненными остатками позволяет вычислить факт правки данных. был случай — штатный программист правил данные прямо в БД по своим обедам (стоимость обедов вычиталась из зарплаты)…
alfaterra
14.09.2018 07:55У меня такая аналогия родилась:
Парк, в котором протоптаны куча дорожек. Администрация решает облагородить парк.
Выделяет деньги на асфальтирование дорожек. Нанимает дизайнера, тот разрабатывает схемы дорожек с точки зрения красоты. Прокладывают дорожки и недоумевают потом как так, почему люди продолжают вытаптывать траву по своим дорожкам. Начинают городить ограждения и прочее. А что мешало сразу разобраться почему именно здесь люди вытоптали дорожку, а не левее на пару метров?
Т.е. это не дыра в заборе, а забор не на своем месте.
BlessYourHeart
13.09.2018 21:13Смешались в кучу… задачи мониторинга, прав доступа, реагирования на несоответствия, своевременного планирования IT инфраструктуры.
«Точечные права» у них появляются через годы существования проблемы, а решение — веселая «засада» (причем с предварительным информированием пользователей путем интервью) — як дити.
leossnet
14.09.2018 12:01С одной стороны, тема отсутствия инженерного (системного) мышления у большинства линейных руководителей, вместо которого можно наблюдать набор религиозно-сектантских практик («делай, как я сказал»), очень актуальна. И описана она достаточно образно и точно.
С другой стороны, концовка как-то смазана. И складывается впечатление, что руководители с системным мышлением оказываются обычными болтунами, когда у них самих дело доходит до принятия конкретного управленческого решения. А хочется больше позитива.
iig
14.09.2018 12:17В руках у эффективного менеджера кнут и пряник. Кнутом он лупит подчиненных, если они косячат. Пряник ест сам.
Система, которая легко и незаметно позволяет проводить чего-то задним числом… Выкинули бы ее, да завели амбарную книгу, раз не умеют ни в менеджмент, ни в безопасность, ни в аудит.
var
16.09.2018 01:48Эм, а я правильно понял конец, что изменения, которые «гадят» в систему вносят сами разработчики? :)
Или у меня извращенное мышление? :)
Akon32
Use grep, Luke!
Я так понимаю, эти ребята в итоге собираются лично записывать логи запросов прав доступа, а потом в реальном времени задавать пользователям вопросы и делать выводы. И их не смущает то, что проблема длится годами, и возможно права вручную тоже годами придётся выдавать, прежде чем что-то найдут.
Не слишком эффективно.
nmivan Автор
и не говорите. Те еще дятлы.
Я не с ними, если что.
vesper-bot
Если проблема длится годами, а при попытке закрыть топорным методом в лучшем случае заметаются следы, то проблема активна и присутствует в настоящий момент. То есть, кто-то лезет не в своё дело слишком часто. Я бы, пожалуй, тут не просто "точечно права повыдавал", а ещё и с флагом audit, то есть, если прав у пользователя реально нет, система действует так, как если они есть, но логирует действия. SELINUX=permissive такой.
Вообще, проблема в том, что они не знают, что им искать. "Как" — use grep, Luke, а "что" — а хрен его знает, на непосвященный взгляд все действия являются валидными. Судя по описанию, прямого уничтожения записей в этом случае нет, т.е. злонамеренные действия не выпирают из БД вот прям явно. Систематизировать права доступа — хороший ход, но проверка корректности их применения должна быть двойной — админ смотрит, кто нарушает, и идет с этим к управляющему системой с той стороны с вопросом "положено ли вот этому пользователю вот такие вещи творить", и корректирует права с аудитом сообразно полученным данным. При подозрении на мухлёж со стороны управляющего — к директору, если уже он мухлюет, то стараться смысла нет, и пора валить (с).
Akon32
Я предполагал, что если у них есть логи и возникла идея их посмотреть, то в логах уже отражены похождения всех пользователей за несколько лет (то есть аудит уже ведётся), достаточно только перебрать ~пару гигабайт (или не пару) информации и дальше можно докладывать начальству. Это можно сделать по-тихому, без необходимости провокаций, ведь всё совершённое уже отражено в логах. И не обязательно перебирать все логи.
Серьёзно дорабатывать информационную систему (вкладывать ресурсы), а потом сообщать пользователям, что им нужно будет согласовывать правки с начальством, и ждать, что они продолжат косячить под бдительным надзором — стратегически неправильно.
Так-то да, но, имхо, они должны были разобраться и вместе с начальством или знающими людьми придумать какие-то инварианты, которые можно автоматизированно проверять, и затем вручную рассматривать сомнительные случаи. Если эти косяки будут концентрироваться у некоторых пользователей — вопросы к ним.
Я сталкивался с подобным, но более простым из-за отсутствия финансового интереса пользователей, случаем (где-то в локалке завёлся вирус-спамер), помогло как раз включение логгирования и анализ логов на следующее утро.
vesper-bot
Вполне может быть, что в логах есть не всё, так как тогда настраивали на насущные действия, а сейчас сменился приоритет. То есть даже от просмотра логов с грепом может не оказаться пользы.
Тут согласен, но я предложил другую модель поведения системы — пользователь сам ничего не согласовывает, но его "неправильные" действия в системе логируются (отдельно), админы их сами по своей инициативе согласовывают с начальством и выясняют, насколько это легальные (были) действия, и если таки да, меняют правила аудита, чтобы это от этого пользователя не логировалось, так как ему можно. А согласовывать каждый чих и впрямь не набегаешься, вся работа колом встанет от первой же фактической ошибки.
Я прочел текст так, что из него следует, что они не знают, что вообще является сомнительным случаем, и из-за этого и кипишуют.