<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Автору большое спасибо за труд публикации статьи, но как то уж надоели эти «ГрафикиДиаграммыРасчётыАнализРегистрацияДетализация и прочее». Всё равно всё сводится к простой формуле: Есть проблема, пиши код и решай её.
Аналитика по типовым причинам, приводящие к инцидентам, может дать только количественную оценку. Например, косяк программиста — 100 случаев, косяк бухгалтерии — 200 случаев. Только вот НА БУДУЩЕЕ предупреждать данные инциденты эта информация не поможет. Программисты приходятуходят виз компании. Всю историю не изучишь….
Монументально!
Основная проблема такого подхода очень большая инерционность в принятии корректирующих мер. И их накопление в гигантские кипы инструкций, которые никто не соблюдает.
(1) ihtiking, Суть доклада была в том, чтобы рассказать о том, как одна компания попыталась применить системный подход к решению инцидентов. И что из этого получилось.
Пхе. Немножко пересказа ISO и немножко собственного опыта. Честно говоря, утомляют эти жж-образные биографические реминесценции. Ибо бесполезны, хоть будь сто раз красиво оформлены. Что в одной компании пошло «на ура», то в другой забуксует, и нет, на самом деле, никаких выводов и никаких best practice, кроме собственно желания участников процесса двигать оный процесс. А посему — скушно, братцы.
Если каждый начнёт мемуарами страдать, тут же не продохнуть будет… Может, лучше и правда просто делом заниматься, а?
Я вот могу рассказать, как одна немаленькая компания не без моей помощи СКК внедряла, и-таки внедрила… Ровно для того, чтобы немецкие аудиторы, строгие ребята из TUV SUD, нужные бумажечки нам выдали. Надо ли говорить, на каком уровне при этом было и осталось истинное качество, или сами догадаетесь?
(4) Yashazz, ну это ИТИЛ — английская методология систем, работающих на базе инцидентов и создающих библиотеку знаний, позволяющую на часто встречающиеся инциденты реагировать быстрее с каждым разом. Ну и цепочка постоянного улучшения. Да, ничего нового, но лучше это прочитать, чем не прочитать — такое вот мое ИМХО.
Но вообще все сводится к хелпдеску…
(4) Yashazz, Рад, что у вас столь богатый профессиональный опыт, что вам такое уже неинтересно. Без подколов, на самом деле рад.
Но. Целью доклада и данной статьи не являлось развеять чью-либо скуку.
Цель — показать ситуацию под определенным углом зрения, в надежде, что это поможет кому-то посмотреть на привычные вещи по новому. И придумать, как он может улучшить работу свою или своей компании.
(5) starik-2005, Не нужно сужать рамки до ITIL и HelpDesk. Понятия инцидента намного шире. И инструментов для управления процессом изменений больше.
Я специально в докладе не делал акцента именно на ИТ. Да, зачастую, защитой от многих «мелких» инцидентов является автоматизированная информационная система, работа с которой построена таким образом, чтобы пользователь не мог сделать что-то неправильно (контроль заполненности реквизитов, контроль остатков при проведении документа и т.п.). Но не нужно ограничиваться этим.
(7) Вы просто не читали шесть томов ITIL, походу. Я не сузил — я расширил.
Форма регистрации сообщения (инцидента) это конечно жуть, слишком как то наворочено.
По идее сначала регистрация и подтверждение сообщения, при чем назначение ответственных за разбор дальнейший не всегда реален и целесообразен.
Далее решают уже аналитики, ну или главарь технической банды (если вообще не сделать двойной вариант: персональное назначение + рынок свободных задач).
Собственно по результату реализации можно уже делать задачу по разработке механизма предотвращения.
Ну это просто, поток мыслей.
Пы.сы. если на картинке схемы бизнес-процесса реальный программный процесс — это просто беда, паника, истерика. Процессы должны быть простыми и понятными, желательно без множеств ветвлений и возвратов. С другой стороны хозяин барин и если надо наладить бюрократию, то начало неплохое ))))))
(9) vandalsvq, Процесс абсолютно реальный и он работает. В базе уже несколько тысяч инцидентов. Чтобы схема (карта маршрута) поместилась на слайде, её пришлось нарисовать «змеей». Если развернуть процесс в «линию» он будет выглядеть значительно проще. Ветвлений не много, а все возвраты возникают только если исполнитель предыдущего этапа сделал свою работу некачественно.
Вот интересно, точка входа в управление инцидентами только одна — пользователь, но ведь бывают инциденты, генерируемые автоматически (средства мониторинга и т.п.). С другой стороны, если в процессе работы приложения произошел сбой, то зачем надеяться, что пользователь обратится за решением проблемы? Ведь можно подключить автоматические средства уведомления об инциденте.
(11) saveug, так и делают. Просто в качестве заказчика тут выступает ИТ, как создатель алгоритма проверки функционала. Робот от имени ИТ и создает данный инцидент, являющийся следствием работы алгоритма проверки на ошибочную ситуацию. В остальных случаях, когда робот не может распознать ошибку, заказчиком инициатором является пользователь. Регулярные ошибки уже могут облекаться в алгоритм, контролирующий те или иные параметры работы системы. И это не только ИТ проблем касается, но и проблем учета. Например, при превышении суммы отгрузки клиенту возникает инцидент, адресованный уполномоченному по данным вопросам сотруднику (или их группе). Если превышение оплаты по заявке на расходование ДС не выше определенного, то инцидент может быть создан финансовому контроллеру, если выше — просто отклонен. Ну и так далее…
(2) Сурикат, добавлю — не только не соблюдают, но и не читают вовсе..
(5) starik-2005, Полностью согласен.
Ps Статья читабельная. Для ознакомления самое то..
Саму методологию ИТила можно несколько лет постигать, ну это если кому интересно..
Доходчиво и лаконично!
(16) speshuric,
Уточню: Не наказывайте за инциденты рядовых исполнителей и нижний (линейный) уровень менеджмента. Средний и высший менеджмент за серьёзные инциденты в их зоне ответственности может пострадать (но не всё подразделение).
(17) speshuric, Это очень важное условие. В докладе я упоминал, что на начальном этапе внедрения процесса было прямое распоряжение высшего руководства содержащее явный запрет любого наказания для всех участников инцидента.